draft-conta-ipv6-flow-label-02.txt

IPv6协议中flow_label的相关RFC

   concerning the diffserv field (traffic class) itself, as outlined in
   [DSCP-Def], {Diffserv], and [Differv-Tun].

   When IPv6 packets are encrypted using ESP Transport or Tunnel Mode
   [IPSec-ESP], the port and protocol numbers are hidden, but the flow
   label is not. Thus MF classification remains possible even for
   encrypted traffic.


9. IANA Considerations

   The IPv6 flow label format specified in this document, is based on
   the Differentiated Services Per Hop Behavior Identification Code (PHB
   ID), specified in [PHB ID]. The PHB ID can be a IANA assigned number.
   [PHD ID] contains a "IANA Considerations Section", following
   guidelines stated in [CONS]. No additional IANA considerations have
   to be made.


10.Acknowledgments

   Some of the ideas in this draft were discussed with Thomas Eklund,
   and Walter Weiss. Jochen Metzler reviewed the specification and
   provided good feedback. The continued scrutiny of Steve Deering
   helped refining the document.


11.References

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


   [Intserv] R. Braden, D. Clark, S. Shenker, "Integrated Services in



Conta & Carpenter         Expires in six months    [Page 21]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


   the Internet Architecture: an Overview", RFC 1633, June 1994.


   [Diffserv] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
   Weiss, "An Architecture for Differentiated Service", RFC 2475,
   December 1998.


   [DSCP-Def] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
   the Differentiated Services Field (DS Field) in the IPv4 and IPv6
   Headers", RFC 2474, December 1998.


   [PHB-ID] D. Black, S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop
   Behavior Identification Codes", RFC 3140, June 2001.


   [Diffserv-Tun] D. Black, "Differentiated Services and Tunnels", RFC
   2983, October 2000.


   [Diffserv-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,
   A. Smith, "Differentiated Services Policy Information Base", Work in
   Progress.


   [DiffServ-MIB]  F. Baker, K. Chan, A. Smith "Management Information
   Base for the Differentiated Services Architecture", Work in Progress.


   [Diffserv-Model] Y. Bernet, S. Blake, A. Smith, D. Grossman, "An
   Informal Management Model for Diffserv Routers", Work in Progress.


   [Diffserv-Flow-Label] A. Conta, B. Carpenter, "A Definition of a IPv6
   Flow Label Classifier", Work in Progress.


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


   [MPLS-Arch] Rosen, E., Viswanathan, A., and Callon, R.,
   "Multiprotocol Label Switching Architecture",  RFC 3031, January
   2001.





Conta & Carpenter         Expires in six months    [Page 22]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


   [MPLS-LDP] L. Anderson, P. Doolan, N. Feldman,  A.  Fredette,  R.
   Thomas, "Label Distribution Protocol", RFC 3036, January 2001.


   [RSVP-TE]  D. O. Awduche, L. Berger, D. Gan. Tony Li, Vijay
   Srinivasan, George Swallow, "RSVP-TE: Extensions to RSVP for LSP
   Tunnels", Work in progress.


   [IPSec-ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Protocol
   (ESP)", RFC 2406, November 1998.


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


   [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
   Considerations Section in RFCs", RFC 2434, October 1998.


   [Assign] Postel, J., etc.. "Assigned Numbers", STD 2, RFC 1700,
   October 1994.


12.Authors' Addresses

   Alex Conta
   Transwitch Corporation
   3 Enterprise Drive
   Shelton, CT 06484
   USA
   Email: [e-mail]

   Brian Carpenter
   IBM
   c/o iCAIR
   Suite 150
   1890 Maple Avenue
   Evanston, IL 60201
   USA
   Email: [e-mail]









Conta & Carpenter         Expires in six months    [Page 23]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


Appendix A: Other Possible IPv6 Flow Label Formats

   This section enumerates several ideas, each with its positive and
   negative aspects.

   A possible solution to the issues discussed in section 5.7 is to
   compress or encode the host-to-host header information, and the
   host-to-host protocol type in the flow label value. This is an
   algorithmic mapping of the port numbers and protocol into the flow
   label. There are several ways in which this could be achieved, but
   only two are suggested in this section.

   Another format mentioned further down in this section is one in which
   the length of the IPv6 headers helps locating in one step the host-
   to-host header for accessing the port information.


A.1  Server Port Format - Short Format

     A possible solution to the issues discussed in section 5.7 is to
     compress or encode the host-to-host header information, and the
     host-to-host protocol type in the flow label value. This is an
     algorithmic mapping of the port numbers and protocol into the flow
     label. There are several ways in which this could be achieved, but
     only three are suggested in this section:

     The Server Port Format is a format which is based on carrying in
     the flow label the server port number of a client/server
     application/communication.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Server Port Number  | H-to-H protocol|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "Server Port Number" is the port number assigned to the server
   side of the client/server application. This provides an
   identification of the application, and the type of application, which
   is a quite good indication of the type of QoS characteristics needed
   for the traffic generated or accepted by that application. Obviously
   it does not provide the finer granularity within the use of one
   application on the same end-nodes, that the use of both source and
   destination ports provide. That is, it cannot differentiate among
   multiple instances of the same application running on the same two
   communicating end-nodes. But for Differentiated services purposes, it
   does not seem to really matter, since it is expected that the several
   instances of an application running on the same two end-nodes, would



Conta & Carpenter         Expires in six months    [Page 24]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


   generate or accept traffic which is of same category, class, or
   behavior.

   The reduced number of bits (12 bits out of 16) limits the value to
   "IANA Well-known ports", that is ports from 1 to 1023, and a subset
   of "IANA registered ports" that is, from 1024 to 4095. Registered
   ports have values between 1024 and 65535 [Assign].

   The "H-to-H protocol" is the host-to-host protocol identifier
   [Assign], that is, TCP, UDP, etc....

   Advantage

   The advantage of this flow label format is that the classification
   rule is the typical 5 or 6 tuple format of a Diffserv M-F Classifier
   [Diffserv-Model], containing the source, and destination addresses,
   the source and destination ports (in which one of the two is
   wildcard), the host to host protocol, and the DSCP field. So no new
   classification rule format is needed, and further, it is possible to
   aggregate parts of the IPv4, and IPv6 classification rules. Note that
   for classifying traffic in both directions, two classification rules
   must be configured. For instance a classification rule for TCP flows
   on port 80, between node A, and node B:

   Source Address:A
   Destination Address:B
   Source Port:*
   Destination Port:80
   Host-to-Host Protocol   6 (TCP)

   would be used for all traffic outgoing, from any port, to port 80.

   Source Address:A
   Destination Address:B
   Source Port:80
   Destination Port:*
   Host-to-Host Protocol   6 (TCP)

   would be used for all traffic outgoing from port 80, to any port.


A.2  Server Port Format - Long Format

   Observation:  Since TCP, and UDP are the two major host-to-host
   protocols that carry port numbers in their protocol headers, the
   field occupied by the "host-to-host" protocol could be reduced to 1
   bit, indicating TCP or UDP, as it follows:
    .sp



Conta & Carpenter         Expires in six months    [Page 25]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  TCP Server Port Number       | Res |0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  UDP Server Port Number       | Res |1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "Res" bits are reserved.

   The "TCP Server Port Number" or "UDP Server Port Number is the 16 bit
   port number assigned to the server side of the client/server
   application.


A.3  Header Length Format

   Another possible solution to the issues discussed in section 5.7 is
   to store the IPv6 headers length, that is the length of the IPv6 main
   headers and IPv6 extensions headers preceding the host-to-host, or
   transport header. The length of the IPv6 headers in the flow label
   value would provide the information which a Diffserv QOS engine
   classifier could use to locate and fetch the source and destination
   ports, and apply those, along with the source and destination address
   and the host-to-host protocol from the flow label, to match the
   source and destination address, the source and destination ports and
   the protocol identifier elements of a Diffserv M-F classifier
   [Diffserv-Model].

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Length of IPv6 Headers |H-to-H protocol|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The "Length of the IPv6 Headers" allows also skipping the IPv6
   headers to access directly the host-by-host header for other
   purposes.

   Additionally, this format is useful for classifying packets that are
   not TCP or UDP, and have no source and destination ports.

   With this 12 bit encoding the maximum length of the IPv6 headers that



Conta & Carpenter         Expires in six months    [Page 26]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


   could be represented is 4Kbytes. However, the restriction on headers
   length can be significantly reduced. IPv6 headers are 8byte aligned,
   therefore the length could be represented as the number of 8byte
   chunks occupied by the headers, in which case the maximum length
   would be 32Kbytes.

   If all of the above formats would be used, then there are two ways to
   separate this last type of encoding from the other two mentioned
   above:

   (i) always use a signaling mechanism to distribute the flow label
   values, and so the type of the format would be stored as part of the
   flow state.

   (ii) use a bit field to discriminate the formats. For instance, a two
   bit field could be used to indicate the first, second, or third type
   of format.

   Note:

   The suggestions described in this section are in fact an exploration
   of possible solutions. Each suggestion has advantages and
   disadvantages. They are kept in this section at least for recording
   purposes.



























Conta & Carpenter         Expires in six months    [Page 27]

1593