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

Versions: 00 01                                                         
Network Working Group                                    Stefan Schmid
Internet Draft                                          Martin Dunmore
Document: draft-schmid-rsvp-fl-01.txt                    Nicholas Race
Expires February 1999                                     Andrew Scott
                                              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 packet processing 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.



Schmid                                                          [Page 1]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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. The Flow Label as Packet Classifier ........................... 6
    5. Implementation of the Flow Label .............................. 8
       5.1. Recommendation ........................................... 8
       5.2. Object Definition ........................................ 8
       5.3. Processing Rules ......................................... 9
       5.4. Reservation Styles .......................................10
       5.4.1. Explicit Sender Selection ..............................10
       5.4.2. Wildcard Sender Selection ..............................11
       5.5. Packet Classification ....................................12
    6. Benefits of Using the Flow Label ..............................13
       6.1. Efficient Packet Classification ..........................13
       6.2. Enabling Network Layer Security Mechanisms ...............15
       6.3. Efficient Packet Forwarding ..............................16
       6.4. Additional Prospects .....................................16
    7. Security Considerations .......................................17
    8. References ....................................................17
    9. Acknowledgments ...............................................19
   10. Authors' Addresses ............................................19
   APPENDIX A. Alternative Solutions .................................20
   APPENDIX B. Revised IPv6 Header ...................................22


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



Schmid                                                          [Page 2]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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 describes alternative
   approaches to the solutions presented throughout this memo.  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.  A discussion on how to ensure unique local flow
   labels is presented in [Deerin98].  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 a flow.  As we will see later,
   this feature has an important impact on the processing of flows
   within RSVP implementations in routers.



Schmid                                                          [Page 3]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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, RSVP routers are now capable of
   classifying packets and mapping their 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, 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 is known as the "layer violation



Schmid                                                          [Page 4]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   problem" [Zhang95].

   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 achieved by determining a
   packet's session and applying the filters of the session.  If the
   packet could be identified as belonging to one of the locally
   registered flows, 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 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, aside from the IPv6 flow label, 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



Schmid                                                          [Page 5]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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 using the flow label as a packet
   classifier.


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 specific QoS requirements or not.  However,
   this benefit can only be fully exploited if the flow label is
   consistently used within RSVP for IPv6.  As a result, we highly
   recommend the mandatory use of the flow label within RSVP for IPv6.




Schmid                                                          [Page 6]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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 [RFC1809].  The implications for RSVP are that any
     packet with an "unknown" flow label is forwarded in the same way
     as normal best-effort traffic.  These packets are treated in the
     same manner as if they would not belong to a flow.

   o How do routers handle flows with equal flow labels?

     In theory, flows with equal flow labels do not cause problems since
     flows are uniquely identified by the pair (source IP address,
     flow label).  However, when taking full advantage of the flow label
     properties, namely uniqueness and randomness, it might be more
     efficient to hash only on the flow label or any set of bits within
     the flow label field.  In the case of a hash collision, the source
     IP address is used to unambiguously distinguish the flows.
     Nevertheless, hash collisions based on the randomly distributed
     flow label 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.





Schmid                                                          [Page 7]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


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 within
   RSVP along with our reasons for discarding them.

   We decided on the following solution since we believe that this is
   the most elegant way to define the usage of the IPv6 flow label
   within RSVP.  As we will see, the number of changes required to the
   original specification is minimal and the implementations are simple.

5.1 Recommendation

   The analysis of the IPv6 flow label properties in section 4 has shown
   that the usage of the flow label within RSVP has provision to greatly
   improve the packet classification processing.  Section 6 explores
   additional benefits of flow label use.  Thus, in order to fully
   exploit their advantages, it is important that flow labels are
   consistently used within RSVP for IPv6 to classify packets.

   As a result, the IPv6 flow label SHOULD be used within RSVP for IPv6.
   Furthermore, we highly recommend that any future standards define
   usage of the flow label to be mandatory.

   We do not suggest that use of the flow label should be compulsory at
   this stage, since there are still IPv6 implementations that do not
   properly support flow label usage.  Since the changes required to
   enable flow label usage are minor, we believe that as soon as
   applications and protocols, i.e. RSVP, make use of the flow label, IP
   software developers and vendors will upgrade their releases.

5.2 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 objects already defined 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 obsolete FILTER_SPEC (Class
   10) and SENDER_TEMPLATE (Class 11) objects with C-Type 3 of the
   original specification.

   The revised filter spec object is shown here:



Schmid                                                          [Page 8]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


      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.  The
   SESSION object may be either the IPv6/UDP SESSION object (C-Type 2),
   as defined in [RFC2205], or the IPv6/GPI SESSION object (C-Type 4),
   as defined in [RFC2207].

   The former uses the destination UDP port as part of the session
   identifier whereas the latter uses a virtual destination port to
   demultiplex sessions beyond the IP destination address.  The virtual
   destination port was introduced to support protocols that do not
   contain transport level ports.

5.3 Processing Rules

   Although the RESV and PATH message formats do not change, the
   processing of these messages will require modification.
   Specifically, the (virtual) destination port and the protocol ID of
   the session object must be used in an appropriate manner for RSVP
   with flow label support.

   According to the Version 1 RSVP specification, the destination port
   and the protocol ID of the session object is used for packet
   classification, especially to choose the reserved resources of a
   flow's packet for sessions with the same destination IP address.
   Since the flow label in RSVP for IPv6 is used as a more efficient
   packet classifier, neither the destination port nor the protocol ID
   is used for that purpose anymore.  Traffic will be mapped
   (classified) to reservations entirely based on the flow identifier,
   namely the tuple (source IP address, flow label).  However, the
   destination ports (DstPort and vDstPort) are still required for
   session management reasons in order to establish multiple
   reservations for different sessions with the same destination.




Schmid                                                          [Page 9]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   Avoiding reliance on the destination port information is absolutely
   necessary in order to resolve the implicit layer violation problem of
   standard RSVP packet classification.  Furthermore, the protocol ID
   should not be used for classification since accessing the protocol ID
   in IPv6 might be very costly due to the variable number of extension
   headers that need to be skipped first.

   As a result of this processing modification, all flows to the same IP
   destination address would share the same reservation when the
   wildcard filter (WF) reservation style is used.  Note, WF style
   reservation messages do not include explicit sender filterspecs.
   However, in section 5.4.2 we present a solution which allows multiple
   WF reservations for the same destination node without need of
   destination ports and protocol IDs for packet classification.

   In order to ensure error-free operation of RSVP with flow label
   support, RSVP implementations in end-user hosts and within the
   network MUST verify the proper use of the flow label field.
   Therefore, if the SENDER_TEMPLATE or FILTER_SPEC object (C-Type 3)
   for flow labels is used in PATH or RESV messages, a unique and
   (pseudo-) random flow label greater than zero MUST be used.  Upon
   receiving a zero flow label, an error message need to be generated.
   We suggest use of the Error Code = 09 in the ERROR_SPEC object to
   indicate that the flow label is unspecified.

5.4 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.4.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.

   Upon receiving a RESV message with FF or SE style, RSVP
   implementations pass the flow identifier of the FILTER_SPEC object
   along with the flow spec of the FLOW_SPEC object to the local packet
   classifier.  Figure 1 illustrates how the RSVP messages are processed
   in order to install the included packet filters in the classifier.






Schmid                                                         [Page 10]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


    PATH: s(DstAddr, PId, vPort)            PATH: s(DstAddr, PId, vPort)
          st(SndAddr, FlowLabel)  --------        st(SndAddr, FlowLabel)
   <---------------------------- |        | <-----------------------------
                                 | RSVPD  |
   ----------------------------> |        | ----------------------------->
    RESV: s(DstAddr, PId, vPort)  --------  RESV: s(DstAddr, PId, vPort)
          filt(SndAddr, FlowLabel)   |            filt(SndAddr, FlowLabel)
          flow(...)                  |            flow(...)
                     filt(SndAddr,   |  flow(...)
                          FlowLabel) |
                                    \ /               s: SESSION
                               -------------         st: SENDER_TEMPLATE
                              | CLASSIFIER  |      flow: FLOW_SPEC
                               -------------       filt: FILTER_SPEC

     Figure 1: Installation of Filters for FF and SE Style Reservations

5.4.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 containing
   the session's destination IP address to the same WF reservation.
   Note, according to the processing rules defined above, we do not make
   use of the destination port and protocol ID to map traffic to
   reservations.  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 can be achieved by transparently (from
   an end user's point of view) simulating the WF reservation style by
   means of SE reservations.

   Upon a received RESV message with WF style, intervening routers could
   identify the corresponding PATH message based on the session object.
   The router can then extract the sender IP address and the flow label
   from the SENDER_TEMPLATE object of the PATH message and pass it as a
   filterspec together with the flow spec to the local packet classifier
   (see Figure 2).

   Consequently, packet classification for flows belonging to a WF style
   reservation is achieved based on individual filterspecs, as in the
   case of FF or SE style reservations.  The drawback of this approach
   is that the RSVP process must reliably update the filterspecs in the
   classifier when path state changes.





Schmid                                                         [Page 11]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


    PATH: s(DstAddr, PId, vPort)             PATH: s(DstAddr, PId, vPort)
          st(SndAddr, FlowLabel)  --------         st(SndAddr, FlowLabel)
   <---------------------------- |        | <-----------------------------
                                 | RSVPD  |
   ----------------------------> |        | ----------------------------->
    RESV: s(DstAddr, PId, vPort)  --------   RESV: s(DstAddr, PId, vPort)
          flow(...)                  |             flow(...)
                                     |
                     filt(SndAddr,   |  flow(...)
                          FlowLabel) |
                                    \ /
                               -------------
                              | CLASSIFIER  |
                               -------------

        Figure 2: Installation of Filter for WF Style Reservations

   This solution, suggested by Bob Braden [Braden94] and Markus Jork,
   makes use of the (virtual) destination port and protocol ID to manage
   multiple sessions with the same destination IP address.  By
   explicitly defining each sender, the IPv6 flow label can be used to
   map (classify) packets to their respective QoS reservations.

   The main disadvantage of this solution is that the scalability
   feature of WF style reservations disappears when using explicit
   filters for each sender.

   However, the advantages of this approach are: it preserves the
   semantics of the WF reservation style from an end user's viewpoint
   and exploits the (virtual) destination port and protocol ID
   exclusively for session management reasons.  Packet classification is
   done entirely based on source address and flow label.  Thus, the
   problem of inefficient classification due to layer violation is
   resolved.

   An alternative approach to resolve the limitation of WF style, which
   is not seen as beneficial as the solution described here, is
   presented in Appendix A.2.

5.5 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 use
   of 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



Schmid                                                         [Page 12]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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 by identifying a
   packet's session and matching the 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



Schmid                                                         [Page 13]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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 filterspec 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
   nature of flow labels.  However, to make sure it is not a collided
   hash entry, the source IP addresses must be matched against the
   filterspec address as a final step.

   Even without exploring the exact costs for each of the operations
   described above, and the actual probability that packets belong to a



Schmid                                                         [Page 14]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


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

   The performance comparison outlined 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



Schmid                                                         [Page 15]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   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 and source address must have the same
   destination address, Hop-by-Hop options header (excluding the Next
   Header field) and Routing header contents.  As a result, by
   exploiting 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 also 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 has provision to
   reduce problems caused by frequent route changes, e.g. route
   "fluttering".

   Currently deployed IP routing protocols cause route changes either
   when "new routes becoming available" for a given destination or as a
   result of "existing routes being lost".  For the latter case, IP
   routing provides a sophisticated error recovery mechanism for RSVP.
   For example, if a link is going down, IP routing protocols try to
   find a new path to a given destination node.  RSVP PATH and RESV
   messages automatically adopt this path and try to establish resource
   reservations for the relevant flows.  A local repair mechanism was
   defined in order to establish reservations on new links immediately



Schmid                                                         [Page 16]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   after a router change.  In the cases when required resources are not
   available on the new link, the flows lose their QoS.  This behavior
   is perfectly acceptable if a route is lost.  However, route changes
   due to "new routes becoming available" are not desirable since they
   might cause unnecessary QoS loss.

   The flow semantics of IPv6 could be exploited in future RSVP
   implementations to support route "pinning" mechanisms for reserved
   flows.  For example, data flows of QoS sensitive real-time streams
   could be "pinned" to a route which would prevent the flow from being
   moved to another route unless this is essential.

   Furthermore, the IPv6 flow label facilitates simplified QoS based
   flow routing techniques when interworking with connection-orientated
   networks such as ISDN and ATM [Race98].

   Finally, 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

   [Braden94] Braden, B., "Presentation: RSVP for IPv6", RSVP working
              group meeting, San Jose, December 1994, online at:
              ftp://ftp.isi.edu/rsvp/ietf.meetings/sanjose.ietf/
              braden.issues.ps.



Schmid                                                         [Page 17]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


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

   [Deerin98] Deering, S. and Hinden, R., "Internet Protocol, Version 6
              (IPv6) Specification", IETF Internet-Draft (work in pro-
              gress), draft-ietf-ipngwg-ipv6-spec-v2-02.txt, August 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.

   [Race98]   Race, N., Dunmore, M., Shepherd, D., "Supporting QoS over
              Heterogeneous Networks using RSVP and IPv6", Proceedings
              of IDC'98 'Technology Serving the Information Society',
              Lisbon, September 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.





Schmid                                                         [Page 18]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


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

   [Zhang95]  Zhang, L., "Presentation: IPv6 Flow Label", RSVP working
              group meeting, Danvers, April 1995, online at:
              ftp://ftp.isi.edu/rsvp/ietf.meetings/danvers.ietf/
              zhang.flow-labels6up.ps


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.  Initial research and prototype implementation
   was carried out in Eurescom project P702 'IPv6 - Opportunities for
   Service Providers and Public Network Operators'.  Special
   appreciation goes to Bob Braden <braden@isi.edu> and Markus Jork
   <jork@kar.dec.com> for their technical advise.  Finally, we like to
   thank Laurent Mathy <laurent@comp.lancs.ac.uk> and Joe Finney
   <joe@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

   Martin Dunmore                           Nicholas Race
   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) 1524 593819                 Phone: (+44) 1524 593819
   EMail: dunmore@comp.lancs.ac.uk          EMail: race@comp.lancs.ac.uk







Schmid                                                         [Page 19]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


A  Alternative Solutions

   This Appendix describes alternative approaches for the various
   solutions presented throughout this memo that could be adopted for
   flow label processing within RSVP along with our reasons for
   discarding them.

A.1 Ignore (Virtual) Destination Port and Protocol ID in SESSION Object

   The approach presented in this section proposes an alternative
   solution for the utilization of the IPv6 flow label within RSVP
   (compare section 5).

   The alternative approach suggests that the (v)DstPort and protocol ID
   of the session object should be ignored avoiding ambiguity by
   mandating it to be zero.  By doing this, we implicitly limit the
   number of sessions per destination to one.

   For RSVP without flow label support, the destination port and
   protocol ID of the session object were required only to enable
   routers to differentiate multiple flows originating from the same
   port and destined to the same IP address.  Without these additional
   identification criterias, all flows would have shared the same
   reservations.  However, when exploiting the flow label within RSVP,
   all flows can be unambiguously distinguished based on the sender
   address and flow label.  Thus, the (virtual) destination port and
   protocol ID of the session object is not necessarily required
   anymore.

   This argument, however, holds only in the case of explicit sender
   selection which is used for FF and SE style reservations.  When using
   WF, due to the lack of filterspecs, all reservations would be
   established with respect to the destination's IP address.  Without
   using the destination port and protocol ID as further demultiplexing
   information, all the flows would automatically share the same
   reservations.

   Nevertheless, since our main concern is to resolve the implicit layer
   violation problem of RSVP which is caused by the dependency of higher
   layer demultiplexing information such as the transport level ports,
   ignoring the (virtual) destination port in the session object seems
   to be the logical conclusion.  However, in section 5.4.2 we have
   shown that the additional session demultiplexing information provided
   by (virtual) destination ports can be used to establish multiple WF
   reservations which do not depend on this higher level information to
   achieve proper packet classification.

   Since we could not gain anything from the "reduced" session



Schmid                                                         [Page 20]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


   semantics, except simplicity, but lost the capability of resolving
   the problem of multiple WF style reservations for a single
   destination, we came to the conclusion that this approach should be
   rejected.

A.2 Use of "Receiver Selected" or "Predefined" Flow Labels

   An alternative approach to resolve the limitation of WF style
   reservations by means of the IPv6 flow label (compare section 5.4.2)
   is to utilize "receiver selected" flow labels.  Here, the destination
   selects the flow label which is then used by the sender to label the
   data packets and by the classifier to map them to their QoS
   reservations.

   One problem arising from the fact that receivers choose the flow
   label is: the flow label must be propagated to the sender nodes.
   This could be done either within the RSVP protocol itself by using
   the RESV message or by means of any session description (e.g. SDP,
   SAP) or session setup protocol (e.g. SIP, RTSP).  In order to
   transmit the flow label, the former approach would demand either a
   modification of the session object or a new definition of the SESSION
   object.

   In the case of multicast sessions with multiple senders and
   receivers, the approach described is not suitable since multiple
   receivers would select different flow labels which would then create
   different sessions.  Therefore, "predefined" flow labels could be
   required.  Session announcement including a flow label could be
   achieved by adopting the currently deployed mechanisms for multicast
   session announcement (i.e. SDP, SAP).

   The advantage of this approach is that packet classifiers require
   only one filter per session for WF style reservations.  In contrast
   to the solutions proposed in section 5.4.2, this practice preserves
   the scalability property of WF style reservations.

   On the other hand, the major drawback of this approach is: it
   implicitly changes the flow label semantics defined in [RFC1889,
   RFC1809].  The flow label would not be "sender selected" anymore.
   This modification causes further problems that would have to be
   resolved first.  For example: how would a sender react on receiving a
   "receiver selected" or "predefined" flow label which is already in
   use by another flow?

   The fact that the flow label semantics (which is a fundamental part
   of the basic IPv6 specification [RFC1889]) would implicitly be
   changed when deploying this alternative approach, led the authors to
   dismiss this alternative.



Schmid                                                         [Page 21]


Internet Draft    RSVP Extension for Flow Label Support      August 1998


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

   See [Deerin98] for further information on the IPv6 protocol.




























Schmid                                                         [Page 22]