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

IPv6协议中flow_label的相关RFC

        address and a non-zero flow label.


   (b)  Packets that do not belong to a flow carry a flow label of zero.



Conta & Carpenter         Expires in six months     [Page 7]




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


   (c)  A flow label is assigned to a flow by the flow's source node.


   (d)  New flow labels must be chosen (pseudo-)randomly and uniformly
        from the range 1 to FFFFF hex. 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.


   (e)  All packets belonging to the same flow must be sent with the
        same source address, destination address, and flow label.


   (f)  If packets of a flow include a Hop-by-Hop Options header, then
        they all must be originated with the same Hop-by-Hop Options
        header contents (excluding the Next Header field of the Hop-by-
        Hop Options header).


   (g)  If packets of a flow include a Routing header, then they all
        must be originated with the same contents in all extension
        headers up to and including the Routing header (excluding the
        Next Header field in the Routing header).


   (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)  The maximum lifetime of any flow-handling state established
        along a flow's path must be specified as part of the description
        of the state-establishment mechanism, e.g., the resource
        reservation protocol or the flow-setup hop-by-hop option.


   (j)  A source must not reuse a flow label for a new flow within the
        maximum lifetime of any flow-handling state that might have been
        established for the prior use of that flow label. When a node
        stops and restarts (e.g., as a result of a "crash"), it must be
        careful not to use a flow label that it might have used for an
        earlier flow whose lifetime may not have expired yet.





Conta & Carpenter         Expires in six months     [Page 8]




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


5. IPv6 Flow and Flow Label Discussion

   This section is going to discuss several aspects of the flow label,
   which are the target of clarifications or improvement.


5.1  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.

   The capability to specify a filter based on source, and destination
   addresses, and flow label presents the advantage of having all the
   filtering elements in one header, as opposed to multiple headers.

5.2  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, nor to exclude explicitly the classification of IPv6
   packets based on flow labels. The definition in [Diffserv-Model] is
   general enough to invite the use of the flow label.

   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, as the IPv6
   specification [IPv6] suggests. To allow and use a wild card source
   address is perhaps debatable. The MF classifier could be extended
   with the destination address, so it would be a 3 element tuple:
   source and destination addresses, and flow label. Range of addresses,
   or range of flow labels may be specified.

   The definition of a MF classifier based on source, and destination
   addresses, and flow label presents the advantage of having all the
   classification elements in one packet header, as opposed to scattered
   in one packet's multiple headers, that is, the IPv6 main header, and
   transport (or host-to-host) header.

   According to the Differentiated Services architecture [Diffserv] the
   classification fields have values according to the Service Level
   Agreemnts (SALs), and Traffic Conditioning Agreements (TCAs),
   (Service Level Specifications -- SLSs, and Traffic Conditioning
   Specifications -- TCSs) which are contractual agreements between
   network clients and network service providers. The flow label based
   Diffserv MF classifier would follow the same model, and would rely on



Conta & Carpenter         Expires in six months     [Page 9]




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


   the flow label which is a field with a value or range of values on
   which clients and service providers would have to agree on. That
   value, or value ranges of the flow labels would be reflected in SLAs,
   TCAs, SLSs, and TCSs.

   As the Diffserv classifier fields are known a priori, before traffic
   is being generated by a source of packets, the same should apply to
   the flow label classifier and the flow label value. This is
   contradicted by a random generation of the flow label value. In order
   to resolve this contradiction, rule marked (d) in Section 4,
   extracted from [IPv6], Appendix A, which states that the flow label
   should be pseudo-random, must be relaxed or removed (a subsequent
   section is a summary of proposals).


5.3  Flow Label based Filtering

   A similar problem as the Multi-Field classifier contradiction
   described in the section above occurs with any type of filtering that
   a forwarding engine may have to perform, in which the filtering rules
   are configured by a network manager, or are loaded in the forwarding
   engine by methods other than a resource reservation protocol, or hop
   by hop signaling. Note that the filtering may have just internal
   purposes to a forwarding engine, or to a router (which is assumed may
   have several forwarding engines), or to a segment of the network, or
   to a network. In all of the cases enumerated above, the expectation,
   or assumption is that the IPv6 header carries in its fields a set of
   predictable, or well determined values. This is not the case, if the
   flow label has a randomly chosen value.

   This problem of not being able to configure or load filtering rules,
   which are based or are including the flow label, can be resolved
   simply by relaxing or removing the rule marked (d) in Section 4,
   extracted from [IPv6], Appendix A, which is that the flow label must
   be a random number.


5.4  End-to-end/Hop-by-hop use of the IPv6 Flow Label

   The definition in [IPv6] gives a definite hop-by-hop characteristic
   to the flow label. The flow label is supposed to help the routing
   system in processing packets whether during packet forwarding, or
   whether during QoS processing. However, controversial discussion took
   place around the end-to-end use and character of the flow label.

   For instance it was stated that the label should be used as a
   mechanism for identifying a flow by the destination end-node. Such
   statements seem to be warranted by the use of the IPv6 pair of source



Conta & Carpenter         Expires in six months    [Page 10]




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


   and destination addresses as component fields in host-to-host
   connection (virtual circuit oriented communication) or communication
   (connectionless oriented) identifiers, and thus the flow label would
   just be an addition or a replacement to such identifiers. However, if
   the routers' packet processing is more performance critical then
   end-nodes' processing, as the author of this document believes, it
   would seem to make more sense to use the flow label for that purpose,
   that is to use the flow label hop-by-hop significance.

   Using a flow label end-to-end or hop-by-hop seem to be fine in the
   context of the current definition of the flow label, as long as the
   non-mutable character of the flow label is maintained. The issue of
   mutable or non-mutable is going to be discussed in a separate
   section.

   The discussion around the end-to-end, or hop-by-hop use of a flow
   label becomes irrelevant if a certain negotiation mechanism amongst
   routers and end-nodes takes place. There are examples of technologies
   in which such negotiations around flow labels and flows labeling take
   place. For instance the Label Distribution Protocol of MPLS [MPLS-
   LDP] is used to exchange labels among neighboring MPLS Routers,
   including the source and the destination of the labeled packets.
   Furthermore, the Resource Reservation Protocol (RSVP) [RSVP] has been
   extended [RSVP-TE] to exchange labels between neighboring label
   switch (MPLS) routers. But such a mechanism, at the time of writing
   this specification, does not exist for IPv6 flow labels, or as part
   of the IPv6 set of specifications. However, such a mechanism could be
   specified in the future, therefore the specification or the
   definition of the IPv6 flow label should not restrict the use of the
   flow label in one way or another relative to its end-to-end or hop-
   by-hop characteristic.

   In conclusion, the flow label could have a bivalent character in the
   type of its usage, or in its significance:

   (i)end-to-end, and

   (ii)hop-by-hop.

   The end-to-end significance should not preclude its hop-by-hop
   significance, and vice-versa. If a node which sends packets,
   associates a certain end-to-end significance to the flow label of
   those packets, that significance can be meaningful also hop-by-hop to
   each downstream router, all the way to the final destination.
   Furthermore, the flow label could be changed in the packet headers by
   the en-route routers, and restored or not to its original value by
   the last hop router, as long as the end-node is aware of what the
   value of the flow label should be. Certainly such a behavior would



Conta & Carpenter         Expires in six months    [Page 11]




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


   need negotiation and state storing in the en-route routers, in
   particular the last hop one.


5.5  Mutable/Non-mutable IPv6 Flow Label

   Another topic of controversial discussion is whether the flow label
   should be mutable or non-mutable, that is it should be read-only for
   routers or not.

   Statements that advocate a non-mutable characteristic are certainly
   based on the advantage of the simplicity implied by such a
   characteristic.

   Opposite statements, that the flow label should be mutable, are based
   on the flexibility that this provides, in particular if the label has
   a hop-by-hop significance. However, using mutable flow labels would
   not work without a certain agreement, or negotiation between
   neighboring nodes (routers), or certain configuration of those
   routers. This would require the use of a negotiation mechanism
   between neighboring routers, or a certain setup through router
   management or configuration, to make sure that the values or the
   changes made to the flow label are known to all routers on the
   portion of the path of the packet, in which the flow label changes.
   Some of these mechanisms, such as MPLS Label Distribution Protocol
   [MPLS-LDP], or RSVP extensions for Traffic Engineering [RSVP-TE},
   were briefly mentioned in the previous section. Such a mechanism
   could be specified for IPv6 flow labels.

   As the hop-by-hop significance of the flow label can be enhanced by a
   mutable characteristic, the specification or definition of the flow
   label should not preclude this.

   A mutable flow label though requires the relaxation or elimination of
   the rules marked (a), (c), (d), and (j) in Section 4. These rules
   were extracted from [IPv6], Appendix A.


5.6  Using Random Numbers in setting the IPv6 Flow Label

   The rule marked (d) in Section 4, extracted from [IPv6], Appendix A,
   specifies the requirement of pseudo-randomness in setting the value
   of a flow label. The reason given is the use of a hashing function,
   and hashing table for flow lookup by routers. Randomness certainly
   helps if the flow label is the only criterion used in the flow
   lookup.

   The use of a hashing mechanism is one possible choice for the flow



Conta & Carpenter         Expires in six months    [Page 12]




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


   lookup in routers, or hosts.

   Another possible choice is to use the label as an index in an array,
   which is a direct and faster lookup, or retrieval of the flow state,
   and so a contiguous set of values, starting from 1, would be more
   helpful, in particular if the flow label is not the only criterion
   used.

   However, the authors of this document believe that the specification
   of the flow label should not mandate any implementation choices,
   whether they are random values, with hashing functions, or just
   contiguous values, with array indexing.

   Furthermore, a random value in the header is introducing the
   unpredictability of the field. Although this may be an argument of
   philosophical nature, predictability is a necessary condition for
   deterministic behavior. Deterministic behavior is a MUST in a
   network. Network operators may require that packets of a flow have
   always the same IPv6 content. Random values in the IPv6 flow label
   certainly break such a requirement.

   To resolve these issues would certainly require the relaxation or
   elimination of rule marked (d), in Section 4, extracted from Appendix
   A of [IPv6].


5.7  IPv6 Multi-Field Classifiers Efficiency

   This section will address multi-field classification engines
   efficiency issues.


5.7.1  Classification Rules Memory Requirements

   When the flow label value is completely independent from host-to-host
   protocol id and source and destination port information, the
   classification rules that contain MF flow label classifiers are at
   least partially independent from the classification rules that
   contain regular MF classifiers. If somewhat the flow label could
   capture the port and host-to-host protocol information, then the flow
   label classifier values could be in their entirety inferred from a
   regular M-F classifier values. This could help in storing
   classification rules in encoding, and perhaps aggregating information
   in ways in which memory consumption could be minimized. However, the
   issue and the gain could be categorized as minor.






Conta & Carpenter         Expires in six months    [Page 13]




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


5.7.2  Pipe-Lined or Parallel Processing Classification.

   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 back to back (contiguous), the position of
   the fields is well-known, and therefore 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, in case of a Multi-Field Classifier, the IPv6 extension
   headers that are potentially located between the IPv6 header and the
   host-to-host protocol header, need to be processed sequentially,
   before having access to the host-to-host protocol id, and the host-
   to-host source and destination ports. This 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 (source and destination ports and protocol id) in the
   classification rules certainly alleviates this issue. Furthermore,
   the use of the flow label, relaxes the issue mentioned previously
   with security headers.


6. Summary of Proposals for the IPv6 Flow Label

   In summary, the following are the actions being proposed: