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]