[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                    Stefan Schmid
Internet Draft                                Lancaster University, UK
Document: draft-schmid-rsvp-fl-00.txt                    Andrew, Scott
Expires February 1999                         Lancaster University, UK
                                                           August 1998


              RSVP Extensions for IPv6 Flow Label Support


Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   This document suggests a proposed protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this draft is unlimited.


Abstract

   This document is an addendum to Version 1 of RSVP (Resource
   ReSerVation Protocol) as defined in the proposed standard [RFC2205].
   The flow label, one of the new header fields of the IPv6 protocol,
   allows improvements to resource reservation protocols on IPv6 capable
   networks.  Utilization of the flow label simplifies packet
   classification and optimizes scheduling in routers along the
   transport path.

   The main objectives of this document are to specify the proper usage
   of the IPv6 flow label and to promote its support within RSVP. This
   memo defines extensions required to the Version 1 specification and
   additional processing rules needed to ensure correct operation.
   Rather than simply presenting the specification with no
   justification, we have tried to present the benefits of adopting the
   flow label within RSVP for IPv6.  This addendum does not have any
   effect on the implementation or usage of RSVP for IPv4.


Table of Contents

    1. Introduction .................................................. 2
    2. Description of the IPv6 Flow Label ............................ 3
    3. The Layer Violation Problem ................................... 4
    4. Flow Label as Packet Classifier ............................... 6
    5. Implementation of the Flow Label .............................. 7
       5.1. Object Definition ........................................ 8
       5.2. Processing Rules ......................................... 8
       5.3. Reservation Styles ....................................... 9
       5.3.1. Explicit Sender Selection .............................. 9
       5.3.2. Wildcard Sender Selection .............................. 9
       5.4. Packet Classification ....................................10
    6. Benefits of Using the Flow Label ..............................10
       6.1. Efficient Packet Classification ..........................10
       6.2. Enabling Network Layer Security Mechanisms ...............12
       6.3. Efficient Packet Forwarding ..............................13
       6.4. Additional Prospects .....................................14
    7. Security Considerations .......................................14
    8. References ....................................................15
    9. Acknowledgments ...............................................16
   10. Authors' Addresses ............................................16
   APPENDIX A. Alternative Solutions .................................16
   APPENDIX B. Revised IPv6 Header ...................................19


1  Introduction

   Today's RSVP implementations in routers suffer from the lack of flow
   semantics within IPv4.  However, the flow label provided with the new
   Internet Protocol Version 6 enables these problems to be overcome.

   We believe that the IPv6 standard is now mature enough for other
   protocols to fully exploit its capabilities. In particular, the
   specification of IPv6 flow label utilization in RSVP should be
   completed.

   The two main objectives of this memo are: firstly, to motivate
   researchers and developers to adopt the flow label as an efficient
   means of classifying packets, and secondly, since the use of the flow
   label is only briefly described in the Version 1 specification of
   RSVP, this memo aims to clearly specify how the flow label should be
   used in RSVP.

   The next section gives a description of the flow label and its
   benefits in the context of resource reservation.  Section 3 discusses
   the problems facing present RSVP implementations in routers due to
   the limitations of IPv4.  Section 4 discusses the use of the flow
   label as a packet classifier.  Section 5 describes the required
   extensions to the RSVP specification necessary for proper utilization
   of the flow label.  Section 6 lists the benefits of using the flow
   label in RSVP.  In Section 7, additional security considerations due
   to the extensions are discussed.  Appendix A presents four
   alternative approaches for utilizing the flow label in RSVP. Appendix
   B outlines the revised IPv6 header of the IPng working group along
   with the discussion leading to the decision.


2  Description of the IPv6 Flow Label

   When the designers of the next generation Internet protocol, IPv6,
   included a 24 bit header field for a flow label, they were convinced
   that the flow identifier was a promising extension to IP.

   According to the IPv6 specification [RFC1883], the flow label field
   might be used by a source to label packets which require special
   handling by intervening IPv6 routers, such as non-default quality of
   service (QoS) or "real-time" service. The idea was to use the flow
   label field to label packets of a data flow with the same value.
   Therefore, the definition of a "flow" comes implicitly from the
   definition of the flow label itself.  A flow is defined as a sequence
   of packets sent from a particular source to the same (unicast or
   multicast) destination for which the source desires special handling
   by the intervening routers. The flow label is assigned to a flow by
   the source or sending node.  A source can never have more than one
   flow with the same flow label at a given time.  Based on this
   definition, flows can be unambiguously distinguished by the
   combination of the source IP address and a non-zero flow label.
   Packets that do not belong to a flow must have their flow label set
   to zero.

   New flow labels must be chosen (pseudo-)randomly and uniformly.  The
   reason for 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.  As we will see later,
   this feature has an important impact on the processing of flows
   within RSVP implementations in routers.

   A more detailed description of the general processing rules for the
   IPv6 flow labels, not related to RSVP, can be read in the IPv6
   specification.  Additional information regarding the usage of the
   IPv6 flow label field is presented in [RFC1809].

   Although the flow label field is 24 bits long according to the IPv6
   specification, the IPng working group within the IETF has recently
   agreed to reduce the flow label size to 20 bits.  In Appendix B, we
   present the revised IPv6 header and a brief summary of the
   discussion.  Further on in this memo, we implicitly assume a flow
   label size of 20 bits, although this does not affect the mechanisms
   described.

   When the IPv6 designers decided to include a flow label in the new IP
   header, they clearly had packet classification in mind. The routers
   along the path between the source and destination use the flow label
   to easily identify packets that are related and may need special
   handling, such as QoS services.  The type of service (TOS) field of
   IPv4 or the Class field of IPv6 is also intended to be used as a
   packet classifier [RFC791, RFC1349]. However, the latter is used to
   classify packets with regard to different service classes, whereas
   the former enables classification in terms of packet/flow
   affiliation.

   The addition of the flow label field provides the IP protocol with
   the concept of a flow.  As a result, routers are now capable of
   managing and servicing flow specific QoS requirements based on IP
   semantics only.

   In the next section, we review how packet classification is achieved
   in the context of RSVP for IPv4 and IPv6 when no notion of flows is
   available.  Besides the "layer violation problem", we address further
   drawbacks regarding the lack of flow semantics.


3  The Layer Violation Problem

   Routers along a reserved path are required to identify packets from
   different data flows in order to process them according to their
   desired QoS needs.  However, since IPv4 does not directly support the
   concept of flows, the intervening routers have to make use of
   transport protocol or application level data to achieve proper packet
   classification.

   The fact that a router which is supposed to process data only at the
   network layer, according to the OSI reference model, requires
   information from the transport or application protocol to provide QoS
   support within RSVP, introduces what we call the "layer violation
   problem".

   According to Version 1 of RSVP, routers with traffic control support
   require a packet classifier responsible for identifying the QoS
   parameters of incoming packets.  Once a packet is classified, it is
   handed over to the packet scheduler which processes it based on its
   QoS requirements.  The classification is done first, by determining
   the session of a packet and second, by applying the filters of a
   session. If the packet is matched by one of the filters, the
   corresponding flowspec defines its QoS requirements.

   A session in RSVP is defined by the triple: (DestAddress, ProtocolId
   [, DstPort]).  Here, DestAddress, the IP destination address of the
   data packets, may be a unicast or multicast address.  ProtocolId is
   the IP protocol ID.  The optional DstPort parameter is a "generalized
   destination port", i.e., some further demultiplexing in the transport
   or application protocol layer.  In present implementations, the
   DstPort is usually defined by the UDP or TCP destination port, since
   UDP and TCP are the only widely deployed transport protocols on the
   Internet at this time.

   A filter spec is defined by the tuple (SrcAddress [, SrcPort]).  Here
   SrcAddress is the IP address of the sending host.  The optional
   SrcPort parameter is also a "generalized source port" that allows
   further differentiation between flows from the same source address.
   The SrcPort is usually defined by the UDP or TCP port of the sending
   application.

   By reviewing the classification process of the currently deployed
   RSVP implementations, it is obvious that routers on IP networks must
   look inside the IP payload to access the UDP or TCP ports within the
   transport protocol header.  This inherent layer violation is
   necessary due to the lack of network level flow semantics within IPv4
   and a result of not exploiting the flow label within RSVP for IPv6.

   Layer violation has serious drawbacks for traffic control performance
   in routers.  Routers have to look inside every arriving packet for
   any destination which has a RSVP session registered in order to
   classify the packet, even if the packet does not belong to a reserved
   flow.  The issue here is that there is no support in IP for
   distinguishing packets that belong to a flow and those that do not.
   In the case of IPv4, accessing the transport protocol ports is not
   too expensive; the IPv4 header explicitly defines the header length
   allowing relatively easy access to the ports.  However, in IPv6 this
   can be a costly task, since all the extension headers need to be
   skipped in order to get to the transport protocol header.
   Furthermore, this performance loss increases the processing time of a
   packet in each intervening router and, as a result, the end-to-end
   delay which is the limiting factor in many real-time streaming
   applications in the first place.

   Another disadvantage caused by the dependency on transport or
   application protocol information is that no IP-level security
   mechanisms can be used in conjunction with RSVP. IP-level Security,
   under either IPv4 or IPv6, may encrypt the entire transport header,
   hiding the port numbers of data packets from intermediate routers.
   In order to overcome this problem, an extension to RSVP for IP
   security under IPv4 and IPv6 was defined in [RFC2207].  However, when
   using RSVP with the IPv6 flow label, this extension will become
   obsolete for IP-level security (see section 6.2 for further
   discussion).

   The lack of flow semantics in IPv4 forces RSVP routers to use "work
   arounds", as described above, for proper classification of data
   packets.  However, in IPv6 networks, the "layer violation problem"
   can be solved by deploying the flow label.  The next section
   discusses the advantages of this approach in detail.


4  The Flow Label as Packet Classifier

   The flow label was added to the IPv6 header to extend the network
   protocol to include the concept of flows supporting the management
   and processing of data streams in the network.

   According to [RFC1809], "real-time flows must obviously always have a
   flow label, since flows are a primary reason flow labels were
   created." Therefore, RSVP which is primarily used to support real-
   time flows by reserving resources for them should not lack a clear
   specification of how the flow label should be used.

   The main purpose of using the flow label in RSVP is to properly set-
   up packet classification in routers in order to improve its
   efficiency.  We will see that the properties of flow labels are ideal
   for this task:

   First, a flow label of zero indicates that a particular packet does
   not belong to a flow.  This allows routers to immediately identify
   (by a simple check within the IPv6 header) whether a packet needs
   special treatment due to QoS needs or not.

   Second, the flow label in conjunction with the source IP address
   uniquely identifies a flow.  This is true because the IPv6
   specification requires that each host ensures unique local flow
   labels.  The great benefit for packet classification is that all the
   information needed to uniquely classify packets is available within
   the IP header, where it should be.

   Third, flow labels are chosen (pseudo-)randomly and uniformly, and
   assigned to a flow by the flow's source node.  The advantage of this
   attribute is that any set of bits within the flow label field should
   be suitable for use as a hash key by routers.  This is extremely
   valuable for use within RSVP, since routers along a reserved path
   need to identify the session to which every packet belongs, and match
   the filter spec in order to access the QoS parameters in the
   flowspec.  Hash table based access to this data can be performed very
   efficiently by using a set of contiguous bits from the flow label as
   a key.

   In summary, utilization of the flow label simplifies the processing
   of traffic control in routers and should greatly improve efficiency.
   Nevertheless, there are still a number of open questions:

   o How do routers deal with packets that carry a flow label that has
     no locally defined state?

     The default rule should be that if a router receives a datagram
     with an unknown flow label, it treats the datagram as if the flow
     label were zero.  A general discussion on how to deal with this
     situation in IPv6 networks is presented in [RFC1809].

     If we assume that the flow label is mainly used within the context
     of RSVP, in a later version of RSVP a router could possibly
     initialize a "local repair" by requesting a PATH message from the
     last hop router upon receipt of a packet with an "unknown" flow
     label.

   o How do routers handle flows with equal flow labels?

     In order for routers to deal with equal flow label values from
     different flows, they must provide special support for such
     "collisions".  If the router uses a hash table for flow state
     information, a sophisticated hash collision mechanism is required,
     although such hash collisions are fairly unlikely if the hash key
     is not too short.  For example, when using 14 bits of the flow
     label as a hash key, the probability of a collision in the local
     flow state table is 1/(2^14) = 1/16384.


5  Implementation of the Flow Label

   The objective of this section is to clearly specify how support for
   the IPv6 flow label should be achieved within RSVP.  It describes the
   changes required to the Version 1 specification and explains
   additional processing rules.  In Appendix A, we present alternative
   approaches that could be adopted for flow label processing with RSVP
   along with our reasons for discarding them.

   We decided on the following solution with a view to minimizing the
   number of changes necessary to the original specification and
   simplifying the implementation.

5.1 Object Definition

   This approach does not require additional session or filter spec
   objects.  Rather than adding new objects to the protocol, we have
   tried to reuse the original objects and simply extend them by adding
   extra processing rules.

   However, since the flow label size in the IPv6 header was revised by
   the IPng working group of the IETF (see Appendix B for further
   information), we decided to redefine the FILTER_SPEC object (Class
   10) and the SENDER_TEMPLATE object (Class 11) with C-Type 3 of the
   original specification.

   Rather than defining new FILTER_SPEC and SENDER_TEMPLATE objects with
   C-Type 4, we decided to redefine the objects since they are now
   obsolete.

   The revised filter spec object is shown here:

      FILTER_SPEC object: Class = 10, C-Type = 3
      +-------------+-------------+-------------+-------------+
      |                                                       |
      +                                                       +
      |                                                       |
      +               IPv6 SrcAddress (16 bytes)              +
      |                                                       |
      +                                                       +
      |                                                       |
      +--------------------+------+-------------+-------------+
      |   ///////          |     Flow Label (20 bits)         |
      +--------------------+------+-------------+-------------+

   The revised SENDER_TEMPLATE object has the same format.

   When using RSVP with flow label support, the revised FILTER_SPEC and
   SENDER_TEMPLATE objects must be used in PATH and RESV messages.

5.2 Processing Rules

   Although the RESV and PATH message formats do not change, the
   processing of these messages will require modification.
   Specifically, the usage of the DstPort field in the SESSION object
   must be revised.

   According to the RSVP specification, a session is defined by the
   triple: (DestAddress, protocol ID, DstPort).  In present
   implementations, the DstPort contains the UDP/TCP destination port,
   specifically "a 16-bit quantity carried at the octet offset +2 in the
   transport header or zero for protocols that lack the notion of
   transport ports."  In RSVP without flow label support, the
   destination port is needed to differentiate flows from the same
   source IP address and port sent to the same destination IP address.
   However, since this requirement becomes obsolete when using the flow
   label, we set the DstPort in the SESSION object to zero.  By doing
   this we implicitly limit the number of sessions per IP address to
   one, but, since sender applications choose unique flow labels for all
   local flows, individual flow reservations can still be unambiguously
   distinguished based on the destination IP address in the SESSION
   object and the FILTER_SPEC (source IP address and flow label).

5.3 Reservation Styles

   The extended processing rules, as described above, have some
   ramifications depending upon the reservation style, namely the
   Fixed-Filter (FF), Shared Explicit (SE), or Wildcard-Filter (WF).

5.3.1 Explicit Sender Selection

   The FF and SE styles have an explicit sender selection.  Therefore,
   the FILTER_SPEC object contains the (SrcAddress, FlowLabel) pair.
   This allows the receiver to uniquely identify senders based on both
   elements of the pair.  When merging explicit sender descriptors, the
   senders may only be considered identical when both elements are
   equal.

5.3.2 Wildcard Sender Selection

   In a WF style reservation, the RESV message does NOT contain a
   FILTER_SPEC since it would be superfluous to specify senders
   explicitly in a "shared" reservation with "wildcard" sender
   selection.  As a result, classifiers may match all packets which
   contain both the session's destination IP address and protocol ID to
   such WF reservations.  Note, according to the processing rules
   defined above, we do not make use of the destination port to identify
   different sessions in order to avoid layer violation problems.
   Therefore, when using WF style reservations, all flows to the same IP
   destination address using the same IP protocol ID will share the same
   reservation.

   A solution for this limitation is not proposed at this time.  This
   issue is not seen as significant since the flow label improves packet
   classification only with respect to reservations based on explicit
   sender selection.

   As a result, when multiple WF style reservations for a particular
   destination are needed, the flow label extension as described in this
   note can not be applied at this stage.  However, there is no
   restriction of using the RSVP without flow label support as described
   in the Version 1 specification in complement. The consequence is less
   efficient QoS support due to layer violations.


5.4 Packet Classification

   Besides the changes necessary to the protocol processing rules, the
   packet classifier also needs to be adapted to make the most of the
   flow label.  These changes are the most promising of all, since the
   flow label allows a significant reduction in the processing cost per
   packet seen by routers.

   In order to enable the packet classifier to access state information
   of active flows with minimal processing cost, it is important that
   local hash tables or databases of flows are indexed by means of the
   flow label.  This modification is essential as the classification of
   data packets is primarily based on the flow label when it is non-
   zero.

   During the transition period, routers will need mechanisms to provide
   fast access to flow state information based on the IP address and
   port, as well as new mechanisms based on the flow label.


6  Benefits of Using the Flow Label

   In this section, we explore the benefits of adopting the flow label
   for IPv6 based RSVP use.

   The most important advantage arising from flow label utilization is
   that it allows RSVP to be implemented without recourse to
   "clandestine" techniques. Due to the flow semantics of IPv6, the
   implicit "layer violation problem" is resolvable.  As shown in
   section 5, routers no longer depend on transport or application level
   protocols to correctly classify packets.

   The next two subsections discuss advantages directly related to the
   avoidance of layer violation.  In section 6.3 and 6.4, we present
   additional benefits of the flow label approach.

6.1 Efficient Packet Classification

   In order to show that packet classification based on the flow label
   improves efficiency, we need some form of measurement to compute the
   processing cost of packet classification in routers in order to
   compare the different approaches.

   For the purpose of illustration, we use a simplified model of the
   packet classifier which processes packets purely in software.  By
   looking at the operations necessary to classify packets for both
   approaches, namely IPv4/IPv6 RSVP without flow label support and IPv6
   RSVP with flow label support, we try to show the complexity decrease
   and efficiency improvement of the flow label utilization.

   In general, packet classification in routers is done first by
   identifying the session of a packet and second by matching a packet
   against the filters of the corresponding session.

   Without support for flow labels, packet classification requires the
   following steps: First, the classifier needs to check whether the
   packet destination IP address belongs to a session.  This address
   lookup could be done by means of hashing.  In order to achieve better
   hashing results, a hash key based on the IP address might have to be
   computed first.  Second, in the case of a hash hit, the DstPort needs
   to be compared with the session description.  This port comparison,
   which is an inherent layer violation, and therefore costly
   (especially for IPv6), must be performed frequently if multiple
   sessions are active for a particular destination node. Third, if the
   port is identical, a check for the correct protocol ID is required.
   This test is performed last since it is likely that the second test
   fails first due to the unsuited distribution of port numbers
   (individual applications use usually the same ports). After the
   identification of the packet's session, the filter spec must be
   matched.  This is done by searching a list of filters associated with
   the session.  In order to find the correct filter, the fourth step,
   comparing the source IP address, needs to be performed.  And finally,
   if it matches any of the filter's addresses, the source port must be
   checked.  This is also very likely, if we assume that sessions have
   multiple flows, for example one for audio and one for video.

   A serious problem in this approach is the inability to identify
   whether a packet belongs to a flow that requires special handling or
   not without performing the expensive classification first.

   Packet classification based on the IPv6 flow label has important
   advantages over the former approach.  As already mentioned in section
   4, the flow label can be used to immediately identify whether packets
   belong to a flow or not.

   Another advantage arising from the flow label property that they are
   (pseudo-)randomly assigned is: the flow label or any set of bits
   within the flow label field can be used as a hash key.  No additional
   cost due to hash key generation is incurred.  Furthermore, since the
   flow label is (pseudo-)randomly selected, it is most likely a
   "better" hash key than a hash key generated from the source address
   in the sense that it causes less hash collisions and, as a result,
   less processing costs for classification.

   In the case of packet classification with flow label support, the
   processing required in the router is much simpler: First, the flow
   label is used as a hash key to look up whether flow state exists for
   a packet. In the case of a hash hit, it is most likely that the
   correct flow state entry is directly identified due to the random
   generation of flow labels.  However, to make sure it is not a
   collided hash entry, the destination IP address must be compared in a
   second step.  Third, if the destination address is equal to the IP
   address in the session description, the protocol ID must be checked.
   And finally, the source IP address needs to be matched against the
   filter spec address.

   Even without exploring the exact costs for each of the operations
   described above, and the actual probability that packets belong to a
   session or flow, it seems clear that the processing efficiency of
   packet classification with flow label is a significant improvement
   over that currently exploited by RSVP.  A more detailed analysis with
   numerical results is given in [Schmid98].

   The main reason for the efficiency gain of the latter approach lies
   in the fact that flow state information can be indexed with the flow
   label as an identifier instead of using a key based on destination IP
   addresses and the avoidance of layer violating operations.

   The performance comparison given here is based on a software
   processing model.  One could easily argue that this does not hold if
   these operations are processed in hardware or with hardware support
   as in real routers.  However, even then, the analysis still gives
   insights about the complexity of the required operations and,
   therefore, provides information about possible hardware
   implementation costs.

6.2 Enabling Network Layer Security Mechanisms

   Network layer security in the currently deployed Internet is usually
   achieved using IP security, or IPSEC, protocols [RFC1825] such as
   packet level authentication [RFC1826] and integrity and
   confidentiality [RFC1827].  The IPSEC extensions provide service by
   adding new headers, namely the Authentication Header (AH) and/or
   Encapsulating Security Payload (ESP), between the IP header and the
   transport protocol header.

   When using the IPSEC protocol within RSVP, first, access to the
   transport protocol ports requires modifications in the case of IPv4
   and second, transport ports might be hidden from intervening routers
   when encryption is used.  Therefore, security mechanisms within
   Version 1 of RSVP are only applicable on a per host, rather than a
   per flow basis.

   Hence, RSVP Extensions for IPSEC were defined in [RFC2207] so that
   data flows containing IPSEC protocols can be controlled at a
   granularity similar to that already specified for UDP and TCP.  The
   RSVP extension proposes the usage of the IPSEC Security Parameter
   Index, or SPI, in place of the UDP/TCP-like ports.  The announcement
   of flow specific SPIs for the intermediate RSVP routers nodes
   requires a new FILTER_SPEC and SESSION object which includes the
   IPSEC SPI.

   However, in IPv6 RSVP, the flow label can be used directly as an
   identifier to distinguish multiple flows from a source address to the
   same destination. The advantage of using the flow label to
   demultiplex flows is that the flow label field of the IPv6 header is
   not encrypted by any network level security mechanism and, therefore,
   it can easily be used for packet classification in conjunction with
   IPSEC by the routers along a reserved path.

   As a result, when using RSVP with flow label support, the IPSEC
   extensions for RSVP become obsolete.

6.3 Efficient Packet Forwarding

   The IP packet forwarding process of routers is computationally
   expensive when options (in IPv4) or extension headers (IPv6) need to
   be processed.  Each packet carrying such additional routing
   information increases the processing load and the end-to-end delay.

   According to the IPv6 specification, all datagrams with the same
   (non-zero) flow label must have the same destination address, Hop-
   by-Hop options header (excluding the Next Header field), Routing
   header and source address contents.  As a result, by using the flow
   label, the IP packet forwarding can be performed more efficiently.
   Simply by looking up the flow label in a flow information table, the
   router can decide how to route and forward the datagram without
   examining the rest of the header.  Therefore, the expensive options
   or extension header processing must not be done on a per packet
   basis.

   In summary, use of the flow label within RSVP allows simplification
   and improvement of the standard IP packet forwarding task.

6.4 Additional Prospects of the Flow Label

   Utilizing the flow label within resource reservation protocols such
   as RSVP for real-time data streaming has, besides the advantages
   mentioned above, additional potential.

   Reserving resources by means of the flow label could solve or at
   least reduce problems caused by frequent route changes, e.g. route
   "flapping".  Route changes without a good reason, i.e. a link going
   down, is dangerous for data streams with strict QoS requirements.
   While a flow might have resources reserved for its data stream on one
   path, it could lose its QoS reservations when the routing protocol
   suddenly decides to use a different route.  The fact that RSVP makes
   use of standard network level routing protocols provides it with
   sophisticated error recovery mechanisms.  This is certainly one of
   the valuable features of RSVP, however, if a route is changed for
   reasons not related to error recovery, data streams suffer from
   temporary QoS breakdown due to lost resources.  In the worst case it
   could happen that after a route change the QoS requirements cannot be
   satisfied due to the lack of resources on the new link.

   The flow semantics of IPv6 has the potential to allow relatively
   simple implementation of mechanisms supporting route "pinning", which
   prevents arbitrary route changes, but still allows route changes if
   an error occurs.  For example, the flow label could be used to
   prevent QoS sensitive streams from being affected from route changes
   due to load balancing.

   In addition, ongoing research in the area of label switching proposes
   approaches that make use of IPv6 flow labels to identify the
   appropriate reservation state of RSVP for a packet based on its label
   value.  Thus, the packet is switched with respect to its reservation
   state.  The Internet Draft [Davie98] suggests a way to distribute
   label bindings using RSVP messages by introducing a new RSVP object
   RSVP_LABEL to carry a label in an RSVP message.


7  Security Considerations

   Since the adoption of the flow label to RSVP as described in this
   note does not introduce new data fields, besides the flow label, and
   does not require additional messages, we can apply the security
   considerations stated in [RFC2205] to this note.

   In addition, the flow label represents another data element about the
   IP flow that might be available to an adversary.  The label values
   might be useful to an adversary engaging in traffic analysis by
   monitoring not only the data packets of the IP flow but also the RSVP
   control messages associated with the flow.  One possible approach to
   prevent such attacks would be the deployment and the use of
   appropriate link-layer encryption mechanisms.  However, protection
   against traffic analysis attacks is outside the scope of this memo.


8  References

   [Davie98]  Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A.,
              Srinivasan, V., and Blake, S., "Use of Label Switching
              With RSVP", IETF Internet-Draft (work in progress),
              draft-ietf-mpls-rsvp-00.txt, March 1998

   [Hinden97] Hinden, B., "Minutes of the IETF IPng Working Group
              Meeting in Munich", August 1997, online at:
              http://www.cs-ipv6.lancs.ac.uk/ipv6/documents/standards/
              general-comms/ietf/ipngwg/ ipngwg-minutes-97aug.txt

   [Schmid98] Schmid, S., Scott, A., Hutchison, D., and Froitzheim, K.,
              "QoS based Real Time Audio Streaming in IPv6 Networks",
              VV98, Proceedings of SPIE Vol. 3529, Internet Routing and
              Quality of Service, Boston, 1998

   [RFC791]   Postel, J., "Internet Protocol", RFC 791, DARPA,
              September 1981.

   [RFC1349]  Almquist, P., "Type of Service in the Internet Protocol
              Suite".  RFC 1349, July 1992.

   [RFC1809]  Partridge, C.,"Using the Flow Label Field in IPv6"
              RFC 1809, June 1995.

   [RFC1825]  Atkinson, R., "Security Architecture for the Internet
              Protocol", RFC 1825, NRL, August 1995.

   [RFC1883]  Deering, S. and Hinden, R., "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon
              Networks, December 1995.

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

   [RFC2207]  Berger, L. and O'Malley, T., "RSVP Extensions for IPSEC
              Data Flows", RFC 2207, September 1997.

   [RFC2209]  Braden, R., Ed., Zhang, "Resource ReSerVation
              Protocol (RSVP) -- Version 1 Message Processing
              Rules", RFC 2209, September 1997.


9  Acknowledgments

   The work presented in this memo was done within CoBrow - a research
   project funded in parts by the European Community under the
   Telematics Applications Program and the Swiss Federal Office of
   Science and Education.  The authors would like to acknowledge
   contributions from Nick Race <race@comp.lancs.ac.uk> and Martin
   Dunmore <dunmore@comp.lancs.ac.uk> who did some early implementation
   extensions to the ISI RSVP daemon rel4.2a2. Special appreciation goes
   to Joe Finney <joe@comp.lancs.ac.uk> and Laurent Mathy
   <laurent@comp.lancs.ac.uk> for their editorial and technical
   comments.


10 Authors' Addresses

   Stefan Schmid                            Dr. Andrew Scott
   Distributed Multimedia RG                Distributed Multimedia RG
   Computing Department                     Computing Department
   Lancaster University                     Lancaster University
   Lancaster LA1 4YR                        Lancaster LA1 4YR
   United Kingdom                           United Kingdom
   Phone: (+44) 7970 419935                 Phone: (+44) 1524 65201
   EMail: sschmid@comp.lancs.ac.uk          EMail: acs@comp.lancs.ac.uk


A  Alternative Solutions

   This Appendix presents four alternative solutions for implementing
   IPv6 flow label support within RSVP.  We describe each of these
   approaches briefly and discuss their advantages and disadvantages
   together with the reasons why we rejected them.

A.1 Use DstPort in SESSION Object

   In this first approach, the DstPort in the SESSION object is used as
   defined in the RSVP specification.  Thus, the DstPort is used in
   conjunction with the destination IP address to identify sessions.
   However, since our main concern is the "layer violation problem"
   caused by the classification of packets based on transport level
   data, we would have to abstain from using the destination port for
   packet classification. As a result, this approach suggests to use the
   DstPort of the SESSION object to "manage" RSVP sessions in the
   routers along a reserved path, but refuses to use the DstPort to
   classify the packets.

   The advantages of this approach is that we change the notion of
   sessions only with respect to packet classification.  Routers can
   still manage multiple sessions for one destination host. The reason
   for rejecting this approach is: why should the destination port be
   specified in the session object if it is used only for administration
   reasons without any gain for resource reservation and packet
   classification.

A.2 Specification of a new SESSION Object

   This approach suggests a new SESSION object (presented below) which
   is capable of carrying the flow label to intervening routers.

   Instead of using the DstPort as a session demultiplexer, the flow
   label would be used for that purpose.  The flow label size demands
   the definition of a new session object since its 20 bits cannot be
   squeezed in the 16 bit DstPort field.

   The advantages of using the flow label as part of the SESSION object
   is that the session concept would hardly be affected with the
   exception of using the flow label to distinguish multiple sessions to
   the same destination node.  The drawbacks are that a new object is
   required.  As a result, the protocol becomes unnecessarily complex
   and significant changes to the current implementations are required
   due to the different size of the revised session object.

      IPv6/UDP SESSION object: Class = 1, C-Type = 3
      +-------------+-------------+-------------+-------------+
      |                                                       |
      +                                                       +
      |                                                       |
      +               IPv6 DestAddress (16 bytes)             +
      |                                                       |
      +                                                       +
      |                                                       |
      +-------------+-------------+-------------+-------------+
      | Protocol Id |     Flags   |          DstPort          |
      +-------------+-------------+-------------+-------------+
      |      ///////      |         Flow Label (20 bits)      |
      +-------------+-------------+-------------+-------------+

A.3 Use Lower 16 Bit of Flow Label in SESSION Object

   This alternative approach, reuses the original SESSION object by
   changing the DstPort field to a FlowLabel field (see below).  As a
   result, the advantages of the last two approaches, namely that
   multiple sessions to the same destination host can be differentiated,
   would be valid as well.  This would be an easy solution with respect
   to the number of changes necessary to the original specification.

   However, since the flow label is larger than the destination port by
   4 bits, only a subset of the bits could be used.  The problem arising
   from cutting off four bits of the flow label is that unresolvable
   collisions might occur.  Although it is very unlikely that a source
   host selects two flow labels with the same 16 lower order bits
   (2^4/2^20 = 1/65536), there would be no chance for routers to resolve
   them. Such a collision would cause a restriction of a single
   reservation for multiple flows.

      IPv6/UDP SESSION object: Class = 1, C-Type = 3
      +-------------+-------------+-------------+-------------+
      |                                                       |
      +                                                       +
      |                                                       |
      +               IPv6 DestAddress (16 bytes)             +
      |                                                       |
      +                                                       +
      |                                                       |
      +-------------+-------------+-------------+-------------+
      | Protocol Id |    Flags    | Flow Label (lower 16 bit) |
      +-------------+-------------+-------------+-------------+

A.4 Redefine Flag Field of SESSION Object

   Our last alternative approach suggests to redefine the flag field in
   the SESSION object to a size of 4 bits.  The 4 bits gained in
   conjunction with the 16 bits of the DstPort could form a new flow
   label field (see below).  Since the flag field is hardly used - only
   the flag E_Police = 0x01 is defined so far - this should not be a
   significant problem at this time.

   The reason for rejecting this approach is that fundamental changes to
   the original specification, and modifications of current
   implementations would be required.

       IPv6/UDP SESSION object: Class = 1, C-Type = 3
      +-------------+-------------+-------------+-------------+
      |                                                       |
      +                                                       +
      |                                                       |
      +               IPv6 DestAddress (16 bytes)             +
      |                                                       |
      +                                                       +
      |                                                       |
      +-------------+-------------+-------------+-------------+
      | Protocol Id | Flags|      Flow Label (20 bits)        |
      +-------------+-------------+-------------+-------------+


B  Revised IPv6 Header

   In the meeting of the IETF in Munich in August 1997, the IPng working
   group agreed to redefine the priority and flow label field
   [Hinden97].

   The Priority field is renamed in a "Class" field and its length is
   enlarged to eight bits.  The fact that a change to the priority
   semantics took place (relative priorities were discarded) due to open
   loop transmission problems, and the need for more control bits to
   improve the congestion avoidance algorithm of RED, led the working
   group to the decision to revise the priority field.

   As a result of the increased length of the "Class" field, the flow
   label field was reduced to 20 bits.  The leading four octets of the
   revised IPv6 header are presented here:

         4        8                      20
      +-----+----------+---------------------------------------+
      | Ver |   Class  |             Flow Label                |
      +-----+----------+---------------------------------------+