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, 20015. 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 onConta & 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 sourceConta & 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 wouldConta & 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 flowConta & 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, 20015.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: