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

IPv6协议中flow_label的相关RFC

   and so a contiguous set of values, starting from 1, would be more
   helpful. However, the author of this document believes that the
   specification of the flow label should not mandate certain
   implementation choices. This would certainly require the relaxation
   or elimination of rule marked (d).


5.4  Flow Label processing by Integrated Services Routers

   The Integrated Services traffic classification based on flow label in
   conjunction with the use of the Resource Reservation Protocols (RSVP)
   for propagating the flow label value seem to be in synchronism. This
   topic does not require further discussion.


5.5  Flow Label processing by Differentiated Services Routers

   At the time of the writing of this document, the Differentiated
   Services architecture definition of classifiers [Diffserv] does not
   seem to include the classification of IPv6 packets based on flow



Conta                       Expires in six months   [Page 7]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101


   labels.

   In order to support the Flow Label, a Differentiated Services IPv6
   classifier definition should be added. This classifier would be a
   multi-field classifier, which would include as classification fields
   at least, the flow label, and the source address. To allow a wild
   card source address is perhaps debatable.

   Secondly, the Differentiated Services architecture does not make a
   direct assumption about how flow label information gets propagated or
   set in routers. Furthermore, according to the afore mentioned
   architecture, the classification fields have values according to the
   SLAs, and TCAs, which are contractual agreements between clients and
   service providers. Therefore, the fields are known a priori, before
   traffic is being generated by a source of packets. Furthermore, as
   these values could be configured, or uploaded into the routers, long
   before traffic is generated, it seems that the pseudo-random
   character of the flow label values contradicts the model assumed by
   the Differentiated Architecture. In order to resolve this
   contradiction, rule marked (d) in Section 4, extracted from [IPv6],
   Appendix A, should be relaxed or removed.


5.6  IPv6 classifiers efficiency

     This section will address classification engines efficiency issues


5.6.1  Classifier pipe-lined or parallel processing.

   As it was stated above, an IPv4 QoS multi-field classification
   engine, performs a lookup of 5 or 6 fields of the IP and Host-to-host
   protocol headers, in the classification rules table. As most of the
   time, these headers are contiguous, the processing can be pipelined
   or parallelized efficiently. Certainly, the existence of one or more
   IPv4 security headers, disturbs the contiguity of the headers, but as
   an encrypted packet would have the host-to-host header encrypted, it
   is likely that its fields would not be part of a classification rule
   for that packet's flow.

   In IPv6, the potential extension headers between the IPv6 header and
   the host-to-host protocols, which need to be processed sequentially,
   adds a certain degree of difficulty in designing a pipe-lining or
   parallel processing mechanism. The use of the flow label as a
   replacement of the host-by-host fields in the classification rules
   certainly alleviates this issue. Furthermore, the use of the flow
   label, relaxes the issue mentioned previously with security headers.




Conta                       Expires in six months   [Page 8]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101


5.6.2  Classification Rules Memory Requirements

   One possible issue is that the classification rules that contain flow
   label values are different than the classification rules that contain
   host-to-host headers, and this possibly would require more memory to
   store the classification rules, in particular if one aggregates IPv4,
   and IPv6 classification rules. However, this issue seems to be minor.

   A possible solution to the issue discussed in this section is to
   compress or encode the host-to-host header information, and the
   host-to-host protocol type in the flow label value. There are several
   ways in which this could be achieved, but only two are suggested in
   this section:

      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|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     or:


      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    IANA Assigned Value                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The "Server Port Number" is the port number assigned to the server
   side of the application. This provides an identification of the
   application. Obviously it does not provide the higher granularity
   within an application that the use of source and destination port
   provides. The reduced number of bits (12 bits out of 16) also reduces
   the specification to "well-known" ports only, and applications.

   The "H-to-H protocol" is the host-to-host protocol identifier, that
   is, TCP, UDP, etc....  It has the same significance and would be used
   the same way as the protocol identifier from a Differentiated
   Services multi-field classification rule.

   The "IANA Assigned Value" is a value that is assigned by IANA for a
   particular application that is using a particular host-to-host
   protocol, and has certain quality of service requirements.  Further
   to be refined.




Conta                       Expires in six months   [Page 9]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101


   Note that there is no differentiation between the two flow labels,
   that is there is no field that would indicate one versus the other.
   It does not need one.


5.7  Summary

   In summary the following are the actions being proposed:

   (i) Write a document that defines a flow label based classifier. This
   is going to be a separate document.

   (ii) A slight change of the flow label definition.

   (iii) Removing characteristics (a), (d), (i), (j)

   (iv) Relaxation of (c ), (e), (f), (g)

   (v) Redefinition of (b)

   As it follows:

   Flow Label Definition

   The IPv6 Flow Label is a 20 bit field in the IPv6 header which may be
   used by a source to label sequences of packets for which it requests
   special handling by the IPv6 routers, such as non-default quality of
   service or "real-time" service.  According to [IPv6], the nature of
   that special handling might be conveyed to the routers by a control
   protocol, such as a resource reservation protocol, or by information
   within the flow's packets themselves, e.g., in a hop-by-hop option.
   It can also be configured in routers, or simply uploaded through
   management procedures.

   The characteristics of IPv6 flows and flow labels are further defined
   as:



     (a)  A flow label of zero means that the flow label field is
          unused, and therefore has no significance for the packet
          processing.


     (b)  A flow label is assigned to a flow by the flow's source node.
          It can be changed en-route, with the condition that its
          original significance be maintained, or restored, when
          necessary. For instance if the source of the flow intended



Conta                       Expires in six months  [Page 10]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101


          that the flow label has a certain significance to the
          destination end-node, than the nodes en-route, that process
          and eventually change the value of the flow label, should make
          sure, in conjunction with the destination end-node, that even
          that if the value or significance has changed en-route, the
          original information gets to its destination.


     (c)  The flow label must have a value between 1 and FFFFF in hex.
          It identifies a flow.

          It can be chosen (pseudo-)randomly in case of use with the
          Integrated Services QoS model, in which the flow label is
          transmitted to all routers on the path of the packet to the
          final destination. The purpose of the random allocation is to
          make any set of bits within the Flow Label field suitable for
          use as a hash key by routers, for looking up the state
          associated with the flow.

          It can have a preset value, from 1 to FFFFF, if used with
          Differentiated Services QoS model. The preset value of the
          flow label can be configured, uploaded, or transmitted in any
          other possible way, as long as it is stored in the
          classification rules of the classification rules tables stored
          in the forwarding engines of routers along the path of the
          flow.


     (d)  In general, all packets belonging to the same flow are sent
          with the same source address, destination address, and flow
          label.  However, flows can be trunked, or aggregated in
          macro-flows. The flows, members of a macro-flow, may have
          different source or destination addresses. The trunking, or
          aggregation of flows is achieved by simply wildcarding some
          bits or all bits in some of the fields of the multi-field
          classification rules, which contain source address,
          destination address, and flow label.


     (h)  The routers or destinations are permitted, but not required,
          to verify that these conditions are satisfied.  If a violation
          is detected, it should be reported to the source by an ICMP
          Parameter Problem message, Code 0, pointing to the high-order
          octet of the Flow Label field (i.e., offset 1 within the IPv6
          packet).


     (i)  There is no lifetime associated with a flow label.



Conta                       Expires in six months  [Page 11]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101


5. Security Considerations

   [tbd]


6. IANA Considerations

   [tbd]


7. Acknowledgments

   [tbd]


8. References

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


   [MPLS-Arch] Rosen, E., Viswanathan, A., and Callon, R.,
   "Multiprotocol Label
    Switching Architecture", Work in Progress, July 2000.


   [MPLS-LDP] L. Anderson, P. Doolan, N. Feldman,  A.  Fredette,  R.
   Thomas,
      "Label Distribution Protocol", Work in Progress, June 2000.


   [MPLS-Encaps] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
   Fedorkow, G.,
      Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress,
   June 2000.


   [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
   Rosen, E.
      and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in
      Progress, June 2000.


   [MPLS-FR] Conta, A., Doolan, P., Malis A.  "MPLS Using LDP and ATM VC
   Switching", Work in
      Progress, June 2000.





Conta                       Expires in six months  [Page 12]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101


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


9. Authors' Addresses

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








































Conta                       Expires in six months  [Page 13]

767