Network Working Group Stefan Schmid Internet Draft Lancaster University, UK Document: draft-schmid-rsvp-fl-00.txt Andrew, Scott Expires February 1999 Lancaster University, UK August 1998 RSVP Extensions for IPv6 Flow Label Support Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this draft is unlimited. Abstract This document is an addendum to Version 1 of RSVP (Resource ReSerVation Protocol) as defined in the proposed standard [RFC2205]. The flow label, one of the new header fields of the IPv6 protocol, allows improvements to resource reservation protocols on IPv6 capable networks. Utilization of the flow label simplifies packet classification and optimizes scheduling in routers along the transport path. The main objectives of this document are to specify the proper usage of the IPv6 flow label and to promote its support within RSVP. This memo defines extensions required to the Version 1 specification and additional processing rules needed to ensure correct operation. Rather than simply presenting the specification with no justification, we have tried to present the benefits of adopting the flow label within RSVP for IPv6. This addendum does not have any effect on the implementation or usage of RSVP for IPv4. Table of Contents 1. Introduction .................................................. 2 2. Description of the IPv6 Flow Label ............................ 3 3. The Layer Violation Problem ................................... 4 4. Flow Label as Packet Classifier ............................... 6 5. Implementation of the Flow Label .............................. 7 5.1. Object Definition ........................................ 8 5.2. Processing Rules ......................................... 8 5.3. Reservation Styles ....................................... 9 5.3.1. Explicit Sender Selection .............................. 9 5.3.2. Wildcard Sender Selection .............................. 9 5.4. Packet Classification ....................................10 6. Benefits of Using the Flow Label ..............................10 6.1. Efficient Packet Classification ..........................10 6.2. Enabling Network Layer Security Mechanisms ...............12 6.3. Efficient Packet Forwarding ..............................13 6.4. Additional Prospects .....................................14 7. Security Considerations .......................................14 8. References ....................................................15 9. Acknowledgments ...............................................16 10. Authors' Addresses ............................................16 APPENDIX A. Alternative Solutions .................................16 APPENDIX B. Revised IPv6 Header ...................................19 1 Introduction Today's RSVP implementations in routers suffer from the lack of flow semantics within IPv4. However, the flow label provided with the new Internet Protocol Version 6 enables these problems to be overcome. We believe that the IPv6 standard is now mature enough for other protocols to fully exploit its capabilities. In particular, the specification of IPv6 flow label utilization in RSVP should be completed. The two main objectives of this memo are: firstly, to motivate researchers and developers to adopt the flow label as an efficient means of classifying packets, and secondly, since the use of the flow label is only briefly described in the Version 1 specification of RSVP, this memo aims to clearly specify how the flow label should be used in RSVP. The next section gives a description of the flow label and its benefits in the context of resource reservation. Section 3 discusses the problems facing present RSVP implementations in routers due to the limitations of IPv4. Section 4 discusses the use of the flow label as a packet classifier. Section 5 describes the required extensions to the RSVP specification necessary for proper utilization of the flow label. Section 6 lists the benefits of using the flow label in RSVP. In Section 7, additional security considerations due to the extensions are discussed. Appendix A presents four alternative approaches for utilizing the flow label in RSVP. Appendix B outlines the revised IPv6 header of the IPng working group along with the discussion leading to the decision. 2 Description of the IPv6 Flow Label When the designers of the next generation Internet protocol, IPv6, included a 24 bit header field for a flow label, they were convinced that the flow identifier was a promising extension to IP. According to the IPv6 specification [RFC1883], the flow label field might be used by a source to label packets which require special handling by intervening IPv6 routers, such as non-default quality of service (QoS) or "real-time" service. The idea was to use the flow label field to label packets of a data flow with the same value. Therefore, the definition of a "flow" comes implicitly from the definition of the flow label itself. A flow is defined as a sequence of packets sent from a particular source to the same (unicast or multicast) destination for which the source desires special handling by the intervening routers. The flow label is assigned to a flow by the source or sending node. A source can never have more than one flow with the same flow label at a given time. Based on this definition, flows can be unambiguously distinguished by the combination of the source IP address and a non-zero flow label. Packets that do not belong to a flow must have their flow label set to zero. New flow labels must be chosen (pseudo-)randomly and uniformly. The reason for the random allocation is to make any set of bits within the flow label field suitable for use as a hash key by routers, for looking up the state associated with the flow. As we will see later, this feature has an important impact on the processing of flows within RSVP implementations in routers. A more detailed description of the general processing rules for the IPv6 flow labels, not related to RSVP, can be read in the IPv6 specification. Additional information regarding the usage of the IPv6 flow label field is presented in [RFC1809]. Although the flow label field is 24 bits long according to the IPv6 specification, the IPng working group within the IETF has recently agreed to reduce the flow label size to 20 bits. In Appendix B, we present the revised IPv6 header and a brief summary of the discussion. Further on in this memo, we implicitly assume a flow label size of 20 bits, although this does not affect the mechanisms described. When the IPv6 designers decided to include a flow label in the new IP header, they clearly had packet classification in mind. The routers along the path between the source and destination use the flow label to easily identify packets that are related and may need special handling, such as QoS services. The type of service (TOS) field of IPv4 or the Class field of IPv6 is also intended to be used as a packet classifier [RFC791, RFC1349]. However, the latter is used to classify packets with regard to different service classes, whereas the former enables classification in terms of packet/flow affiliation. The addition of the flow label field provides the IP protocol with the concept of a flow. As a result, routers are now capable of managing and servicing flow specific QoS requirements based on IP semantics only. In the next section, we review how packet classification is achieved in the context of RSVP for IPv4 and IPv6 when no notion of flows is available. Besides the "layer violation problem", we address further drawbacks regarding the lack of flow semantics. 3 The Layer Violation Problem Routers along a reserved path are required to identify packets from different data flows in order to process them according to their desired QoS needs. However, since IPv4 does not directly support the concept of flows, the intervening routers have to make use of transport protocol or application level data to achieve proper packet classification. The fact that a router which is supposed to process data only at the network layer, according to the OSI reference model, requires information from the transport or application protocol to provide QoS support within RSVP, introduces what we call the "layer violation problem". According to Version 1 of RSVP, routers with traffic control support require a packet classifier responsible for identifying the QoS parameters of incoming packets. Once a packet is classified, it is handed over to the packet scheduler which processes it based on its QoS requirements. The classification is done first, by determining the session of a packet and second, by applying the filters of a session. If the packet is matched by one of the filters, the corresponding flowspec defines its QoS requirements. A session in RSVP is defined by the triple: (DestAddress, ProtocolId [, DstPort]). Here, DestAddress, the IP destination address of the data packets, may be a unicast or multicast address. ProtocolId is the IP protocol ID. The optional DstPort parameter is a "generalized destination port", i.e., some further demultiplexing in the transport or application protocol layer. In present implementations, the DstPort is usually defined by the UDP or TCP destination port, since UDP and TCP are the only widely deployed transport protocols on the Internet at this time. A filter spec is defined by the tuple (SrcAddress [, SrcPort]). Here SrcAddress is the IP address of the sending host. The optional SrcPort parameter is also a "generalized source port" that allows further differentiation between flows from the same source address. The SrcPort is usually defined by the UDP or TCP port of the sending application. By reviewing the classification process of the currently deployed RSVP implementations, it is obvious that routers on IP networks must look inside the IP payload to access the UDP or TCP ports within the transport protocol header. This inherent layer violation is necessary due to the lack of network level flow semantics within IPv4 and a result of not exploiting the flow label within RSVP for IPv6. Layer violation has serious drawbacks for traffic control performance in routers. Routers have to look inside every arriving packet for any destination which has a RSVP session registered in order to classify the packet, even if the packet does not belong to a reserved flow. The issue here is that there is no support in IP for distinguishing packets that belong to a flow and those that do not. In the case of IPv4, accessing the transport protocol ports is not too expensive; the IPv4 header explicitly defines the header length allowing relatively easy access to the ports. However, in IPv6 this can be a costly task, since all the extension headers need to be skipped in order to get to the transport protocol header. Furthermore, this performance loss increases the processing time of a packet in each intervening router and, as a result, the end-to-end delay which is the limiting factor in many real-time streaming applications in the first place. Another disadvantage caused by the dependency on transport or application protocol information is that no IP-level security mechanisms can be used in conjunction with RSVP. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. In order to overcome this problem, an extension to RSVP for IP security under IPv4 and IPv6 was defined in [RFC2207]. However, when using RSVP with the IPv6 flow label, this extension will become obsolete for IP-level security (see section 6.2 for further discussion). The lack of flow semantics in IPv4 forces RSVP routers to use "work arounds", as described above, for proper classification of data packets. However, in IPv6 networks, the "layer violation problem" can be solved by deploying the flow label. The next section discusses the advantages of this approach in detail. 4 The Flow Label as Packet Classifier The flow label was added to the IPv6 header to extend the network protocol to include the concept of flows supporting the management and processing of data streams in the network. According to [RFC1809], "real-time flows must obviously always have a flow label, since flows are a primary reason flow labels were created." Therefore, RSVP which is primarily used to support real- time flows by reserving resources for them should not lack a clear specification of how the flow label should be used. The main purpose of using the flow label in RSVP is to properly set- up packet classification in routers in order to improve its efficiency. We will see that the properties of flow labels are ideal for this task: First, a flow label of zero indicates that a particular packet does not belong to a flow. This allows routers to immediately identify (by a simple check within the IPv6 header) whether a packet needs special treatment due to QoS needs or not. Second, the flow label in conjunction with the source IP address uniquely identifies a flow. This is true because the IPv6 specification requires that each host ensures unique local flow labels. The great benefit for packet classification is that all the information needed to uniquely classify packets is available within the IP header, where it should be. Third, flow labels are chosen (pseudo-)randomly and uniformly, and assigned to a flow by the flow's source node. The advantage of this attribute is that any set of bits within the flow label field should be suitable for use as a hash key by routers. This is extremely valuable for use within RSVP, since routers along a reserved path need to identify the session to which every packet belongs, and match the filter spec in order to access the QoS parameters in the flowspec. Hash table based access to this data can be performed very efficiently by using a set of contiguous bits from the flow label as a key. In summary, utilization of the flow label simplifies the processing of traffic control in routers and should greatly improve efficiency. Nevertheless, there are still a number of open questions: o How do routers deal with packets that carry a flow label that has no locally defined state? The default rule should be that if a router receives a datagram with an unknown flow label, it treats the datagram as if the flow label were zero. A general discussion on how to deal with this situation in IPv6 networks is presented in [RFC1809]. If we assume that the flow label is mainly used within the context of RSVP, in a later version of RSVP a router could possibly initialize a "local repair" by requesting a PATH message from the last hop router upon receipt of a packet with an "unknown" flow label. o How do routers handle flows with equal flow labels? In order for routers to deal with equal flow label values from different flows, they must provide special support for such "collisions". If the router uses a hash table for flow state information, a sophisticated hash collision mechanism is required, although such hash collisions are fairly unlikely if the hash key is not too short. For example, when using 14 bits of the flow label as a hash key, the probability of a collision in the local flow state table is 1/(2^14) = 1/16384. 5 Implementation of the Flow Label The objective of this section is to clearly specify how support for the IPv6 flow label should be achieved within RSVP. It describes the changes required to the Version 1 specification and explains additional processing rules. In Appendix A, we present alternative approaches that could be adopted for flow label processing with RSVP along with our reasons for discarding them. We decided on the following solution with a view to minimizing the number of changes necessary to the original specification and simplifying the implementation. 5.1 Object Definition This approach does not require additional session or filter spec objects. Rather than adding new objects to the protocol, we have tried to reuse the original objects and simply extend them by adding extra processing rules. However, since the flow label size in the IPv6 header was revised by the IPng working group of the IETF (see Appendix B for further information), we decided to redefine the FILTER_SPEC object (Class 10) and the SENDER_TEMPLATE object (Class 11) with C-Type 3 of the original specification. Rather than defining new FILTER_SPEC and SENDER_TEMPLATE objects with C-Type 4, we decided to redefine the objects since they are now obsolete. The revised filter spec object is shown here: FILTER_SPEC object: Class = 10, C-Type = 3 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +--------------------+------+-------------+-------------+ | /////// | Flow Label (20 bits) | +--------------------+------+-------------+-------------+ The revised SENDER_TEMPLATE object has the same format. When using RSVP with flow label support, the revised FILTER_SPEC and SENDER_TEMPLATE objects must be used in PATH and RESV messages. 5.2 Processing Rules Although the RESV and PATH message formats do not change, the processing of these messages will require modification. Specifically, the usage of the DstPort field in the SESSION object must be revised. According to the RSVP specification, a session is defined by the triple: (DestAddress, protocol ID, DstPort). In present implementations, the DstPort contains the UDP/TCP destination port, specifically "a 16-bit quantity carried at the octet offset +2 in the transport header or zero for protocols that lack the notion of transport ports." In RSVP without flow label support, the destination port is needed to differentiate flows from the same source IP address and port sent to the same destination IP address. However, since this requirement becomes obsolete when using the flow label, we set the DstPort in the SESSION object to zero. By doing this we implicitly limit the number of sessions per IP address to one, but, since sender applications choose unique flow labels for all local flows, individual flow reservations can still be unambiguously distinguished based on the destination IP address in the SESSION object and the FILTER_SPEC (source IP address and flow label). 5.3 Reservation Styles The extended processing rules, as described above, have some ramifications depending upon the reservation style, namely the Fixed-Filter (FF), Shared Explicit (SE), or Wildcard-Filter (WF). 5.3.1 Explicit Sender Selection The FF and SE styles have an explicit sender selection. Therefore, the FILTER_SPEC object contains the (SrcAddress, FlowLabel) pair. This allows the receiver to uniquely identify senders based on both elements of the pair. When merging explicit sender descriptors, the senders may only be considered identical when both elements are equal. 5.3.2 Wildcard Sender Selection In a WF style reservation, the RESV message does NOT contain a FILTER_SPEC since it would be superfluous to specify senders explicitly in a "shared" reservation with "wildcard" sender selection. As a result, classifiers may match all packets which contain both the session's destination IP address and protocol ID to such WF reservations. Note, according to the processing rules defined above, we do not make use of the destination port to identify different sessions in order to avoid layer violation problems. Therefore, when using WF style reservations, all flows to the same IP destination address using the same IP protocol ID will share the same reservation. A solution for this limitation is not proposed at this time. This issue is not seen as significant since the flow label improves packet classification only with respect to reservations based on explicit sender selection. As a result, when multiple WF style reservations for a particular destination are needed, the flow label extension as described in this note can not be applied at this stage. However, there is no restriction of using the RSVP without flow label support as described in the Version 1 specification in complement. The consequence is less efficient QoS support due to layer violations. 5.4 Packet Classification Besides the changes necessary to the protocol processing rules, the packet classifier also needs to be adapted to make the most of the flow label. These changes are the most promising of all, since the flow label allows a significant reduction in the processing cost per packet seen by routers. In order to enable the packet classifier to access state information of active flows with minimal processing cost, it is important that local hash tables or databases of flows are indexed by means of the flow label. This modification is essential as the classification of data packets is primarily based on the flow label when it is non- zero. During the transition period, routers will need mechanisms to provide fast access to flow state information based on the IP address and port, as well as new mechanisms based on the flow label. 6 Benefits of Using the Flow Label In this section, we explore the benefits of adopting the flow label for IPv6 based RSVP use. The most important advantage arising from flow label utilization is that it allows RSVP to be implemented without recourse to "clandestine" techniques. Due to the flow semantics of IPv6, the implicit "layer violation problem" is resolvable. As shown in section 5, routers no longer depend on transport or application level protocols to correctly classify packets. The next two subsections discuss advantages directly related to the avoidance of layer violation. In section 6.3 and 6.4, we present additional benefits of the flow label approach. 6.1 Efficient Packet Classification In order to show that packet classification based on the flow label improves efficiency, we need some form of measurement to compute the processing cost of packet classification in routers in order to compare the different approaches. For the purpose of illustration, we use a simplified model of the packet classifier which processes packets purely in software. By looking at the operations necessary to classify packets for both approaches, namely IPv4/IPv6 RSVP without flow label support and IPv6 RSVP with flow label support, we try to show the complexity decrease and efficiency improvement of the flow label utilization. In general, packet classification in routers is done first by identifying the session of a packet and second by matching a packet against the filters of the corresponding session. Without support for flow labels, packet classification requires the following steps: First, the classifier needs to check whether the packet destination IP address belongs to a session. This address lookup could be done by means of hashing. In order to achieve better hashing results, a hash key based on the IP address might have to be computed first. Second, in the case of a hash hit, the DstPort needs to be compared with the session description. This port comparison, which is an inherent layer violation, and therefore costly (especially for IPv6), must be performed frequently if multiple sessions are active for a particular destination node. Third, if the port is identical, a check for the correct protocol ID is required. This test is performed last since it is likely that the second test fails first due to the unsuited distribution of port numbers (individual applications use usually the same ports). After the identification of the packet's session, the filter spec must be matched. This is done by searching a list of filters associated with the session. In order to find the correct filter, the fourth step, comparing the source IP address, needs to be performed. And finally, if it matches any of the filter's addresses, the source port must be checked. This is also very likely, if we assume that sessions have multiple flows, for example one for audio and one for video. A serious problem in this approach is the inability to identify whether a packet belongs to a flow that requires special handling or not without performing the expensive classification first. Packet classification based on the IPv6 flow label has important advantages over the former approach. As already mentioned in section 4, the flow label can be used to immediately identify whether packets belong to a flow or not. Another advantage arising from the flow label property that they are (pseudo-)randomly assigned is: the flow label or any set of bits within the flow label field can be used as a hash key. No additional cost due to hash key generation is incurred. Furthermore, since the flow label is (pseudo-)randomly selected, it is most likely a "better" hash key than a hash key generated from the source address in the sense that it causes less hash collisions and, as a result, less processing costs for classification. In the case of packet classification with flow label support, the processing required in the router is much simpler: First, the flow label is used as a hash key to look up whether flow state exists for a packet. In the case of a hash hit, it is most likely that the correct flow state entry is directly identified due to the random generation of flow labels. However, to make sure it is not a collided hash entry, the destination IP address must be compared in a second step. Third, if the destination address is equal to the IP address in the session description, the protocol ID must be checked. And finally, the source IP address needs to be matched against the filter spec address. Even without exploring the exact costs for each of the operations described above, and the actual probability that packets belong to a session or flow, it seems clear that the processing efficiency of packet classification with flow label is a significant improvement over that currently exploited by RSVP. A more detailed analysis with numerical results is given in [Schmid98]. The main reason for the efficiency gain of the latter approach lies in the fact that flow state information can be indexed with the flow label as an identifier instead of using a key based on destination IP addresses and the avoidance of layer violating operations. The performance comparison given here is based on a software processing model. One could easily argue that this does not hold if these operations are processed in hardware or with hardware support as in real routers. However, even then, the analysis still gives insights about the complexity of the required operations and, therefore, provides information about possible hardware implementation costs. 6.2 Enabling Network Layer Security Mechanisms Network layer security in the currently deployed Internet is usually achieved using IP security, or IPSEC, protocols [RFC1825] such as packet level authentication [RFC1826] and integrity and confidentiality [RFC1827]. The IPSEC extensions provide service by adding new headers, namely the Authentication Header (AH) and/or Encapsulating Security Payload (ESP), between the IP header and the transport protocol header. When using the IPSEC protocol within RSVP, first, access to the transport protocol ports requires modifications in the case of IPv4 and second, transport ports might be hidden from intervening routers when encryption is used. Therefore, security mechanisms within Version 1 of RSVP are only applicable on a per host, rather than a per flow basis. Hence, RSVP Extensions for IPSEC were defined in [RFC2207] so that data flows containing IPSEC protocols can be controlled at a granularity similar to that already specified for UDP and TCP. The RSVP extension proposes the usage of the IPSEC Security Parameter Index, or SPI, in place of the UDP/TCP-like ports. The announcement of flow specific SPIs for the intermediate RSVP routers nodes requires a new FILTER_SPEC and SESSION object which includes the IPSEC SPI. However, in IPv6 RSVP, the flow label can be used directly as an identifier to distinguish multiple flows from a source address to the same destination. The advantage of using the flow label to demultiplex flows is that the flow label field of the IPv6 header is not encrypted by any network level security mechanism and, therefore, it can easily be used for packet classification in conjunction with IPSEC by the routers along a reserved path. As a result, when using RSVP with flow label support, the IPSEC extensions for RSVP become obsolete. 6.3 Efficient Packet Forwarding The IP packet forwarding process of routers is computationally expensive when options (in IPv4) or extension headers (IPv6) need to be processed. Each packet carrying such additional routing information increases the processing load and the end-to-end delay. According to the IPv6 specification, all datagrams with the same (non-zero) flow label must have the same destination address, Hop- by-Hop options header (excluding the Next Header field), Routing header and source address contents. As a result, by using the flow label, the IP packet forwarding can be performed more efficiently. Simply by looking up the flow label in a flow information table, the router can decide how to route and forward the datagram without examining the rest of the header. Therefore, the expensive options or extension header processing must not be done on a per packet basis. In summary, use of the flow label within RSVP allows simplification and improvement of the standard IP packet forwarding task. 6.4 Additional Prospects of the Flow Label Utilizing the flow label within resource reservation protocols such as RSVP for real-time data streaming has, besides the advantages mentioned above, additional potential. Reserving resources by means of the flow label could solve or at least reduce problems caused by frequent route changes, e.g. route "flapping". Route changes without a good reason, i.e. a link going down, is dangerous for data streams with strict QoS requirements. While a flow might have resources reserved for its data stream on one path, it could lose its QoS reservations when the routing protocol suddenly decides to use a different route. The fact that RSVP makes use of standard network level routing protocols provides it with sophisticated error recovery mechanisms. This is certainly one of the valuable features of RSVP, however, if a route is changed for reasons not related to error recovery, data streams suffer from temporary QoS breakdown due to lost resources. In the worst case it could happen that after a route change the QoS requirements cannot be satisfied due to the lack of resources on the new link. The flow semantics of IPv6 has the potential to allow relatively simple implementation of mechanisms supporting route "pinning", which prevents arbitrary route changes, but still allows route changes if an error occurs. For example, the flow label could be used to prevent QoS sensitive streams from being affected from route changes due to load balancing. In addition, ongoing research in the area of label switching proposes approaches that make use of IPv6 flow labels to identify the appropriate reservation state of RSVP for a packet based on its label value. Thus, the packet is switched with respect to its reservation state. The Internet Draft [Davie98] suggests a way to distribute label bindings using RSVP messages by introducing a new RSVP object RSVP_LABEL to carry a label in an RSVP message. 7 Security Considerations Since the adoption of the flow label to RSVP as described in this note does not introduce new data fields, besides the flow label, and does not require additional messages, we can apply the security considerations stated in [RFC2205] to this note. In addition, the flow label represents another data element about the IP flow that might be available to an adversary. The label values might be useful to an adversary engaging in traffic analysis by monitoring not only the data packets of the IP flow but also the RSVP control messages associated with the flow. One possible approach to prevent such attacks would be the deployment and the use of appropriate link-layer encryption mechanisms. However, protection against traffic analysis attacks is outside the scope of this memo. 8 References [Davie98] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., Srinivasan, V., and Blake, S., "Use of Label Switching With RSVP", IETF Internet-Draft (work in progress), draft-ietf-mpls-rsvp-00.txt, March 1998 [Hinden97] Hinden, B., "Minutes of the IETF IPng Working Group Meeting in Munich", August 1997, online at: http://www.cs-ipv6.lancs.ac.uk/ipv6/documents/standards/ general-comms/ietf/ipngwg/ ipngwg-minutes-97aug.txt [Schmid98] Schmid, S., Scott, A., Hutchison, D., and Froitzheim, K., "QoS based Real Time Audio Streaming in IPv6 Networks", VV98, Proceedings of SPIE Vol. 3529, Internet Routing and Quality of Service, Boston, 1998 [RFC791] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981. [RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite". RFC 1349, July 1992. [RFC1809] Partridge, C.,"Using the Flow Label Field in IPv6" RFC 1809, June 1995. [RFC1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995. [RFC1883] Deering, S. and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon Networks, December 1995. [RFC2205] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2207] Berger, L. and O'Malley, T., "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RFC2209] Braden, R., Ed., Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. 9 Acknowledgments The work presented in this memo was done within CoBrow - a research project funded in parts by the European Community under the Telematics Applications Program and the Swiss Federal Office of Science and Education. The authors would like to acknowledge contributions from Nick Race <race@comp.lancs.ac.uk> and Martin Dunmore <dunmore@comp.lancs.ac.uk> who did some early implementation extensions to the ISI RSVP daemon rel4.2a2. Special appreciation goes to Joe Finney <joe@comp.lancs.ac.uk> and Laurent Mathy <laurent@comp.lancs.ac.uk> for their editorial and technical comments. 10 Authors' Addresses Stefan Schmid Dr. Andrew Scott Distributed Multimedia RG Distributed Multimedia RG Computing Department Computing Department Lancaster University Lancaster University Lancaster LA1 4YR Lancaster LA1 4YR United Kingdom United Kingdom Phone: (+44) 7970 419935 Phone: (+44) 1524 65201 EMail: sschmid@comp.lancs.ac.uk EMail: acs@comp.lancs.ac.uk A Alternative Solutions This Appendix presents four alternative solutions for implementing IPv6 flow label support within RSVP. We describe each of these approaches briefly and discuss their advantages and disadvantages together with the reasons why we rejected them. A.1 Use DstPort in SESSION Object In this first approach, the DstPort in the SESSION object is used as defined in the RSVP specification. Thus, the DstPort is used in conjunction with the destination IP address to identify sessions. However, since our main concern is the "layer violation problem" caused by the classification of packets based on transport level data, we would have to abstain from using the destination port for packet classification. As a result, this approach suggests to use the DstPort of the SESSION object to "manage" RSVP sessions in the routers along a reserved path, but refuses to use the DstPort to classify the packets. The advantages of this approach is that we change the notion of sessions only with respect to packet classification. Routers can still manage multiple sessions for one destination host. The reason for rejecting this approach is: why should the destination port be specified in the session object if it is used only for administration reasons without any gain for resource reservation and packet classification. A.2 Specification of a new SESSION Object This approach suggests a new SESSION object (presented below) which is capable of carrying the flow label to intervening routers. Instead of using the DstPort as a session demultiplexer, the flow label would be used for that purpose. The flow label size demands the definition of a new session object since its 20 bits cannot be squeezed in the 16 bit DstPort field. The advantages of using the flow label as part of the SESSION object is that the session concept would hardly be affected with the exception of using the flow label to distinguish multiple sessions to the same destination node. The drawbacks are that a new object is required. As a result, the protocol becomes unnecessarily complex and significant changes to the current implementations are required due to the different size of the revised session object. IPv6/UDP SESSION object: Class = 1, C-Type = 3 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | DstPort | +-------------+-------------+-------------+-------------+ | /////// | Flow Label (20 bits) | +-------------+-------------+-------------+-------------+ A.3 Use Lower 16 Bit of Flow Label in SESSION Object This alternative approach, reuses the original SESSION object by changing the DstPort field to a FlowLabel field (see below). As a result, the advantages of the last two approaches, namely that multiple sessions to the same destination host can be differentiated, would be valid as well. This would be an easy solution with respect to the number of changes necessary to the original specification. However, since the flow label is larger than the destination port by 4 bits, only a subset of the bits could be used. The problem arising from cutting off four bits of the flow label is that unresolvable collisions might occur. Although it is very unlikely that a source host selects two flow labels with the same 16 lower order bits (2^4/2^20 = 1/65536), there would be no chance for routers to resolve them. Such a collision would cause a restriction of a single reservation for multiple flows. IPv6/UDP SESSION object: Class = 1, C-Type = 3 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | Flow Label (lower 16 bit) | +-------------+-------------+-------------+-------------+ A.4 Redefine Flag Field of SESSION Object Our last alternative approach suggests to redefine the flag field in the SESSION object to a size of 4 bits. The 4 bits gained in conjunction with the 16 bits of the DstPort could form a new flow label field (see below). Since the flag field is hardly used - only the flag E_Police = 0x01 is defined so far - this should not be a significant problem at this time. The reason for rejecting this approach is that fundamental changes to the original specification, and modifications of current implementations would be required. IPv6/UDP SESSION object: Class = 1, C-Type = 3 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags| Flow Label (20 bits) | +-------------+-------------+-------------+-------------+ B Revised IPv6 Header In the meeting of the IETF in Munich in August 1997, the IPng working group agreed to redefine the priority and flow label field [Hinden97]. The Priority field is renamed in a "Class" field and its length is enlarged to eight bits. The fact that a change to the priority semantics took place (relative priorities were discarded) due to open loop transmission problems, and the need for more control bits to improve the congestion avoidance algorithm of RED, led the working group to the decision to revise the priority field. As a result of the increased length of the "Class" field, the flow label field was reduced to 20 bits. The leading four octets of the revised IPv6 header are presented here: 4 8 20 +-----+----------+---------------------------------------+ | Ver | Class | Flow Label | +-----+----------+---------------------------------------+