[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

IPng Working Groups                     A. Conta (Transwitch)
INTERNET-DRAFT                          B. Carpenter (IBM)
                                         July 2001


                   A proposal for the IPv6 Flow Label

                             Specification

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


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   At the time when the IPv6 specifications were written, the IPv6 flow
   label was still experimental, and subject to change, as the
   requirements for flow support in the Internet were evolving.

   The last several years of work in IETF on Internet Protocols Quality
   of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching
   (MPLS) provide a more solid and ample architectural perspective, and
   framework for the standardization of the IPv6 flow label. The new
   charter of the IPv6 Working Group invites contributions to this
   standardization.

   This memo provides an analysis of the IPv6 definition of the flow
   label, the rules governing its use, and their implications. It



Conta & Carpenter         Expires in six months     [Page 1]


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


   subsequently makes a proposal for additions/modifications to these
   rules, which improve the usability of the IPv6 flow label, in
   particular with Diffserv, and its acceptance as a standard mechanism.
















































Conta & Carpenter         Expires in six months     [Page 2]


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


Table of Contents





   1. Introduction....................................................4
   2. IPv6 Flows......................................................5
   3. Other Definitions of Flows......................................5
      3.1 Integrated Services Flows...................................5
      3.2 Differentiated Services Flows...............................6
      3.3 MPLS Flows..................................................7
   4. IPv6 Flow Label.................................................7
   5. IPv6 Flow and Flow Label Discussion.............................9
      5.1 Flow Label Processing by Integrated Services Routers........9
      5.2 Flow Label Processing by Differentiated Services Routers....9
      5.3 Flow Label based Filtering.................................10
      5.4 End-to-end/Hop-by-hop use of the IPv6 Flow Label...........10
      5.5 Mutable/Non-Mutable IPv6 Flow Label........................12
      5.6 Using Random Numbers in setting the IPv6 Flow Label........12
      5.7 IPv6 Multi-Field Classifier Efficiency.....................13
          5.7.1 Classification Rules Memory Requirements.............13
          5.7.2 Pipe-Lined or Parallel Processing Classification.....14
   6. Summary of Proposals for the IPv6 Flow Label...................14
   7. IPv6 Flow Label Definition and Characteristics.................15
      7.1 IPv6 Flow Label Format.....................................17
          7.1.1 Diffserv IPv6 Flow Label Format......................17
          7.1.2 Other Possible IPv6 Flow Label Formats...............18
      7.2 Conceptual Model for Diffserv use of IPv6 Flow Labels......18
   8. Security Considerations........................................21
   9. IANA Considerations............................................21
   10. Acknowledgments...............................................21
   11. References....................................................21
   12. Authors' Addresses............................................23
   Appendix A........................................................24
















Conta & Carpenter         Expires in six months     [Page 3]


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


1. Introduction


   As stated by [IPv6], at the time when the IPv6 specifications were
   written, the IPv6 flow label was still experimental, and subject to
   change, as the requirements for flow support in the Internet were
   evolving.

   The last several years of work in IETF on Internet Protocols Quality
   of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching
   (MPLS) provide a more solid and ample architectural perspective, and
   framework for the standardization of the IPv6 flow label. The new
   charter of the IPv6 Working Group invites contributions to this
   standardization.

 Note: The IETF work on Intserv, Diffserv, MPLS is documented in several
 specifications, among which the architecture documents [Intserv],
 [Diffserv], and respectively [MPLS-Arch].  Intserv and Diffserv present
 two alternative solutions to resolving QoS problems in the Internet,
 while MPLS is a technology based on labeling traffic flows.

   The IPv6 flow label is a function that, as it was designed, can be
   used towards a more efficient processing of packets in next hop
   lookup, quality of service, or packet filtering engines in IPv6
   forwarding devices. These devices would normally be IPv6 routers or
   switches. However, the current IPv6 flow label definition and
   specification can be further clarified or even improved, in
   particular in regards to Differentiated Services Quality of Service
   (Diffserv).

   Diffserv seems to have more potential, and could be used more
   extensively than originally thought. For instance, for IP QoS in
   access networks, Diffserv could be used on individual flows of
   traffic between users and the access networks.  The nature of the
   contractual agreements between the users and the access network
   providers seem to create an environment in which Diffserv with
   Multi-Field (M-F) classifiers could be easier to use, more efficient,
   and more practical as an alternative to Intserv and RSVP.

   However, the Diffserv M-F classifiers, the 5 or 6 element tuple,
   containing host-to-host protocol id, and source and destination
   ports, is a bit of a problem when packets have extension headers
   (IPv4, or IPv6). In IPv6, that is even more of an efficiency problem
   (need for sequential inspection), since extension headers have a much
   wider and frequent use.

   The IPv6 flow label, and the use of IPv6 flow label classifiers would
   be a big help in alleviating this problem. An IPv6 flow label



Conta & Carpenter         Expires in six months     [Page 4]


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


   classifier is basically a 3 element tuple - source and destination
   IPv6 addresses, and the IPv6 flow label [Diffserv-Flow-Label]. It is
   an alternative to the 5 element tuple (addresses, ports, and
   protocol).  It will help the IPv6 flow label to achieve, as it is
   supposed,  a more efficient processing of packets in quality of
   service engines in IPv6 forwarding devices.

   This specification provides an analysis of the definition of the IPv6
   flow label [IPv6], the rules governing its use, and attempts to make
   clarifications to their implications. It subsequently suggests some
   additions, or modifications to these rules, which in the view of the
   authors, improve the usability of the IPv6 flow label, in particular
   with Diffserv, and its acceptance as a standard mechanism.

   The keywords MUST, MUST NOT, MAY, OPTIONAL,  REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT  are to be interpreted as
   defined in [KEYWORDS].


2. IPv6 Flows

   A flow is a sequence of packets sent from a particular source, and a
   particular application running on the source host, using a particular
   host-to-host protocol for the transmission of data over the Internet,
   to a particular (unicast or multicast) destination, and particular
   application running on the destination host, or hosts, with a certain
   set of traffic, and quality of service requirements.


3. Other Definitions of Flows

   As IPv6 relies on Quality of Service Mechanisms defined by the
   Integrated Services Architecture or the Differentiated Services
   Quality of Service Architecture, it is worth considering those
   architectures flow definitions.  The MPLS architecture also defines a
   technique of labeling flows worth considering.


3.1  Integrated Services Flows

   The Integrated Services architecture [Intserv] defines a flow as an
   abstraction which is a distinguishable stream of related datagrams
   that results from a single user activity and requires the same QoS.
   For example, a flow might consist of one transport connection or one
   video stream between a given host pair.  It is the finest granularity
   of packet stream distinguishable by the Integrated Services.

   Furthermore, the Integrated Services architecture [Intserv] defines a



Conta & Carpenter         Expires in six months     [Page 5]


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


   classifier:

     For the purpose of traffic control (and accounting), each incoming
     packet must be mapped into some class; all packets in the same
     class get the same treatment from the packet scheduler.  This
     mapping is performed by the classifier. Choice of a class may be
     based upon the contents of the existing packet header(s) and/or
     some additional classification number added to each packet.

     A class might correspond to a broad category of flows, e.g., all
     video flows or all flows attributable to a particular organization.
     On the other hand, a class might hold only a single flow.  A class
     is an abstraction that may be local to a particular router; the
     same packet may be classified differently by different routers
     along the path.  For example, backbone routers may choose to map
     many flows into a few aggregated classes, while routers nearer the
     periphery, where there is much less aggregation, may use a separate
     class for each flow.


3.2  Differentiated Services Flows

   The Differentiated Services architecture [Diffserv] defines a flow or
   microflow as a single instance of an application-to-application flow
   of packets, which is identified by the source address, source port,
   destination address, destination port and protocol id (fields in the
   IP and host-to-host protocol headers).

   Furthermore, this architecture defines a classifier as:

     a mechanism that selects packets in a traffic stream based on the
     content of some portions of the packet header.  Two types of
     classifiers are defined.  The BA (Behavior Aggregate) Classifier
     classifies packets based on the DS codepoint only.  The MF (Multi-
     Field) classifier [Diffserv-Model] selects packets based on the
     value of a combination of one or more header fields, such as source
     address, destination address, DS field, protocol ID, source port
     and destination port numbers, and other information such as
     incoming interface.

     Classifiers are used to "steer" packets matching some specified
     rule to an element of a traffic conditioner for further processing.
     Classifiers must be configured by some management procedure in
     accordance with the appropriate TCA.

   Note: For the purpose of this document, only a portion of the
   definition of the classifier from the architecture [Diffserv] is
   mentioned.



Conta & Carpenter         Expires in six months     [Page 6]


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


3.3  MPLS Flows

   As it travels from its source to its final destination, an IP packet
   is being forwarded from one router to the next, each router making an
   independent forwarding decision (next hop) based on the packet's IP
   header, and routing information processed and stored.  Choosing the
   next hop can be thought of as the composition of two functions. The
   first function partitions the entire set of possible packets into a
   set of "Forwarding Equivalence Classes (FECs)" [MPLS-Arch]. The
   second maps each FEC to a next hop.  Insofar as the forwarding
   decision is concerned, different packets, which get mapped into the
   same FEC, are indistinguishable. All packets, which belong to a
   particular FEC, and which travel from a particular node, will follow
   the same path (or if certain kinds of multi-path routing are in use,
   they will all follow one of a set of paths associated with the FEC).
   In MPLS, the assignment of a particular packet to a particular FEC
   results in a label being associated to that FEC. When a packet is
   forwarded to its next hop, the label is sent along with it; that is,
   the packets are "labeled" before they are forwarded. Once a packet is
   labeled, at subsequent hops, the forwarding is done based on the MPLS
   label rather than the information in the IP header. The label is used
   as an index into a table which specifies the next hop, and a new
   label.  The old label is replaced with the new label, and the packet
   is forwarded to its next hop.


4. IPv6 Flow Label

   The IPv6 Flow Label is defined [IPv6] as 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.

   The characteristics of IPv6 flows and flow labels, or the rules that
   govern the flow label functions are further defined in [IPv6]. For
   the purpose of this document the text from one paragraph in [IPv6]
   was rearranged as an item list, as follows:


   (a)  A flow is uniquely identified by the combination of a source
        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:

   1. For the Differentiated Services M-F Classification rules to
   include the IPv6 flow label classifer:

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

   (ii)Make a slight change to the flow label definition, by introducing
   the Diffserv flow label format.

   (iii)Rules in Appendix A of [IPv6], do not apply to Diffserv IPv6
   flow labels.

   2. For the Diffserv IPv6 flow labels:

   (i) Redefine characteristics or rules (a), (b), (c), (i), (j) for
   Diffserv IPv6 Flow Labels.




Conta & Carpenter         Expires in six months    [Page 14]


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


   (ii) Remove characteristics (e), (f), (g) for Diffserv IPv6 flow
   labels. They prevent certain ways of aggregating flows into one flow.

   The following section, contains the text that specifies the newly
   suggested IPv6 flow label definition and rules. They would apply to
   Diffserv flows, and to the use of flow label based non-QoS filtering.
   They could also apply to Intserv flows, since there is no technical
   reason that would prevent that.


7. IPv6 Flow Label Definition and Characteristics

   The IPv6 Flow Label is a 20 bit field in the IPv6 header which may be
   used to label packets of the same packet flow, or aggregation of
   flows. This labeling can be used by IPv6 Quality of Service engines
   in routers, for packet classification, policing, and scheduling. It
   can also be used by IPv6 filtering engines in routers, that use
   filtering for various purposes. Documenting such filtering purposes
   is beyond the scope of this document.

   The flow label values can be communicated to routers through a
   resource reservation protocol, by a flow label distribution protocol,
   or by information within the flow's packets themselves, e.g., in a
   hop-by-hop option. They can also be configured in routers, manually,
   or by ways of some automated procedures, or simply uploaded through
   management or policy control procedures.

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



   (a)  A flow is uniquely identified by the combination of source
        address, destination address and a non-zero flow label. Diffserv
        flows MAY be aggregated by specifying a range of addresses
        and/or a range of flow labels (see further in (e)).


   (b)  A flow label of zero means that the flow label has no
        significance, the field is unused, and therefore has no effect
        on, or for the packet processing by forwarding, QOS, or
        filtering engines.


   (c)  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 that the flow label



Conta & Carpenter         Expires in six months    [Page 15]


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


        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 when the value or significance
        has changed en-route, the original information and significance
        is restored when or before the packet arrives to its
        destination.

        If the action to be performed on a particular flow label is not
        known, a router MUST not change the value of that flow label.


   (d)  The flow label must have a value between 1 and FFFFF in hex. It
        identifies a flow. It is a preset value. No particular method is
        preferred for choosing the value. However, the value MUST
        satisfy the following requirements:

        (i) It can be communicated to all routers on the path of the
        flow to the final destination, as well as the destination node,
        by ways of a resource reservation protocol, a flow label
        distribution protocol, a signaling mechanism, or by any other
        means. The first method is typical for the Integrated Services
        model.

        (ii) It can be configured, uploaded, or transmitted to a router
        or a group of routers in any other possible way, as long as it
        can be stored in the classification rules tables of the
        forwarding engines of routers along the path of the flow to the
        final destination. If the flow label is used within a
        Differentiated Services framework, the values of the flow labels
        are preset or agreed upon, and specified in a Service Level
        Agreement (SLA), Service Level Specification (SLS), Traffic
        Conditioning Agreement (TCA), or Traffic Conditioning
        Specification (TCS) [Diffserv]. This model is typical of
        Differentiated Services.


   (e)  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. In
        other words range addresses and/or flow labels can be used.





Conta & Carpenter         Expires in six months    [Page 16]


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


   (f)  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).


   (g)  The Diffserv flow labels to not have a time to live rule.
        However, changes to the value of a flow label of a flow, and/or
        the correspondent flow label classifier values MUST be
        synchronized. When the flow label value of a flow is changed,
        the change must be reflected in the change of the value of the
        flow label in the multi-Field flow label classifier.



7.1  IPv6 Flow Label Format


   In order to preserve compatibility with the random number method of
   selecting a flow label value defined in [IPv6], but relax that
   definition to allow a flow label format that would work with
   Diffserv, the following new format of the flow label could be used:

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|       Pseudo-Random Value           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1|     Diffserv IPv6 Flow Label        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.1.1  Diffserv IPv6 Flow Label Format

   The Diffserv IPv6 Flow Label is a number that is constructed based on
   the Differentiated Services "Per Hop Behavior Identification Code"
   (PHB ID) [PHB ID]:







Conta & Carpenter         Expires in six months    [Page 17]


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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1| Per Hop Behavior Ident. Code  | Res |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "Res" bits  are reserved.

   Conforming to [PHB ID], the PHB ID is either directly derived from a
   standard differentiated services code point [DSCP-Def], or it is an
   "IANA Assigned Value". In either case, it captures the differentiated
   services treatment intended to be applied to the packet. Unlike the
   value of the traffic class field, it is not locally mapped and is
   therefore suitable for use in an end to end header field. Although it
   captures less specific information than the port numbers and protocol
   number normally used in an MF classifier, it nevertheless allows for
   MF classification at a differentiated service domain ingress.


7.1.2  Other Possible IPv6 Flow Label Formats

   There are various other ways in which a Flow Label can be encoded,
   each way with its advantages and disadvantages. Several ideas of flow
   label encoding are enumerated in Appendix A.


7.2  Conceptual Model for Diffserv use of IPv6 Flow Label

   Diffserv can be used in IPv6 access networks for IPv6 QoS of
   individual flows of traffic between users and the access networks.
   The nature of the contractual agreements between the users and the
   access network providers create an environment in which Diffserv with
   Multi-Field (M-F) classifiers could be easier to use, more efficient,
   and more practical as an alternative to Intserv and RSVP.

   The IPv6 flow label classifier is basically a 3 element tuple -
   source and destination IPv6 addresses, and the IPv6 flow label
   [Diffserv-Flow-Label]. It is an alternative to the 5 element tuple
   (addresses, ports, and protocol).  It helps the IPv6 flow label to
   achieve, as it is supposed,  a more efficient processing of packets
   in quality of service engines in IPv6 forwarding devices.

   Whether using algorithmic mapping of port numbers and protocol, IANA
   values, or just a number randomly chosen, the key for the flow label
   to work with Diffserv is that the "flow_label value" or range of
   values MUST be known, and agreed by two sides: the network client and
   the network provider. The "flow label value" is captured in SLAs,
   SLSs, TCAs, TCSs. For the mechanism to work several things have to



Conta & Carpenter         Expires in six months    [Page 18]


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


   happen:


(1.) Packets leaving the client networks carry the correct flow label
     value.  This can be achieved in several ways:

     a. end-node IPv6 protocol stacks, and/or IPv6 applications can be
     configured with the flow label "value". The flow label "value" is
     set first by an application. If the application has not set a flow
     label "value", then the "value" is set by the protocol stack. The
     default values would be hard-coded in applications and protocol
     stacks, or could result from "algorithmic mapping", if such
     mappings exists. The default value could be zero, in which case the
     flow label would have no significance. According to this model,
     when packets are transmitted, end-nodes will force the correct flow
     label in the IPv6 headers of outgoing packets.

             if a. is not TRUE, then

      b. the first hop routers would have to force the correct flow
      label on packets leaving the network. To accomplish this role,
      these routers would be configured with MF classifiers. These
      routers would classify the traffic that is forwarded downstream
      from, and away from the originating end-nodes. The action
      subsequent to the classification would be to set the correct flow
      label in each packet.  Classification on such a router's input
      line card, or interface would result, for the matching packets, in
      a correct flow label being forced in the IPv6 headers of packets
      when they are transmitted on the output interface or line card.

   while it is likely that "b." would not be needed,  "a." or "b." would
   provide the correct flow label in packets leaving the client's
   network.


(2.) Packets coming into the provider network can be policed based on
     flow label. The provider, based on the SLAs, SLSs, TCAs, TCSs
     agreed with the client, configures MF classifiers that look like:

       C = (SA, SAPrefix, DA, DAPrefix, Flow-Label)

     or

       C' = (SA, SAPrefix, DA, DAPrefix, Flow-label-Min:FLow-label-Max)

     Another representation of the classifier for example is:





Conta & Carpenter         Expires in six months    [Page 19]


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


           Flow-label-classifier:
           Type:                   IPv6-3-tuple
           IPv6DestAddrValue:      1:2:3:4:5:6:7:8::1
           IPv6DestPrefixLength:   128
           IPv6SrcAddrValue:       8:7:6:5:4:3:2:1::2
           IPv6SrcPrefixLength:    128
           IPv6FlowLabel:          57

     or

           Flow-label-classifier:
           Type:                   IPv6-3-tuple
           IPv6DestAddrValue:      1:2:3:4:5:6:7:8::1
           IPv6DestPrefixLength:   128
           IPv6SrcAddrValue:       8:7:6:5:4:3:2:1::2
           IPv6SrcPrefixLength:    128
           IPv6FlowLabelMin:       1
           IPv6FlowLabelMax:      57

     and

           Flow-label-classifier:
           Type:                   IPv6-4-tuple
           IPv6DestAddrValue:      1:2:3:4:5:6:7:8::1
           IPv6DestPrefixLength:   128
           IPv6SrcAddrValue:       8:7:6:5:4:3:2:1::2
           IPv6SrcPrefixLength:    128
           IPv6FlowLabel:          57
           IPv6DSCP:               28

     or

           Flow-label-classifier:
           Type:                   IPv6-4-tuple
           IPv6DestAddrValue:      1:2:3:4:5:6:7:8::1
           IPv6DestPrefixLength:   128
           IPv6SrcAddrValue:       8:7:6:5:4:3:2:1::2
           IPv6SrcPrefixLength:    128
           IPv6FlowLabelMin:       1
           IPv6FlowLabelMax:       57
           IPv6DSCP:               28

     The classifiers are configured in the network provider's edge
     routers, etc...

     The classification engines in those routers would match packet
     header information to classification rules as follows:




Conta & Carpenter         Expires in six months    [Page 20]


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


             Incoming packet header (SA, DA, Flow Label)
           Match
             Classification rules table entry (C or C')

   From this step, the Diffserv processing continues the same way as for
   any other MF Classifier [Diffserv-Model].



8. Security Considerations

   This document introduces no new security concerns when the pseudo-
   random flow label format is used. In the case of a diffserv flow
   label, the security concerns are essentially identical to those
   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: aconta@txc.com

   Brian Carpenter
   IBM
   c/o iCAIR
   Suite 150
   1890 Maple Avenue
   Evanston, IL 60201
   USA
   Email: brian@hursley.ibm.com









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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/