idnits 2.17.1 draft-schmid-rsvp-fl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 919 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2205]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1826' is mentioned on line 563, but not defined ** Obsolete undefined reference: RFC 1826 (Obsoleted by RFC 2402) == Missing Reference: 'RFC1827' is mentioned on line 564, but not defined ** Obsolete undefined reference: RFC 1827 (Obsoleted by RFC 2406) == Unused Reference: 'RFC2209' is defined on line 710, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'Davie98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hinden97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schmid98' ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) ** Downref: Normative reference to an Informational RFC: RFC 1809 ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Downref: Normative reference to an Informational RFC: RFC 2209 Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Stefan Schmid 2 Internet Draft Lancaster University, UK 3 Document: draft-schmid-rsvp-fl-00.txt Andrew, Scott 4 Expires February 1999 Lancaster University, UK 5 August 1998 7 RSVP Extensions for IPv6 Flow Label Support 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 This document suggests a proposed protocol for the Internet 28 community, and requests discussion and suggestions for improvements. 29 Distribution of this draft is unlimited. 31 Abstract 33 This document is an addendum to Version 1 of RSVP (Resource 34 ReSerVation Protocol) as defined in the proposed standard [RFC2205]. 35 The flow label, one of the new header fields of the IPv6 protocol, 36 allows improvements to resource reservation protocols on IPv6 capable 37 networks. Utilization of the flow label simplifies packet 38 classification and optimizes scheduling in routers along the 39 transport path. 41 The main objectives of this document are to specify the proper usage 42 of the IPv6 flow label and to promote its support within RSVP. This 43 memo defines extensions required to the Version 1 specification and 44 additional processing rules needed to ensure correct operation. 45 Rather than simply presenting the specification with no 46 justification, we have tried to present the benefits of adopting the 47 flow label within RSVP for IPv6. This addendum does not have any 48 effect on the implementation or usage of RSVP for IPv4. 50 Table of Contents 52 1. Introduction .................................................. 2 53 2. Description of the IPv6 Flow Label ............................ 3 54 3. The Layer Violation Problem ................................... 4 55 4. Flow Label as Packet Classifier ............................... 6 56 5. Implementation of the Flow Label .............................. 7 57 5.1. Object Definition ........................................ 8 58 5.2. Processing Rules ......................................... 8 59 5.3. Reservation Styles ....................................... 9 60 5.3.1. Explicit Sender Selection .............................. 9 61 5.3.2. Wildcard Sender Selection .............................. 9 62 5.4. Packet Classification ....................................10 63 6. Benefits of Using the Flow Label ..............................10 64 6.1. Efficient Packet Classification ..........................10 65 6.2. Enabling Network Layer Security Mechanisms ...............12 66 6.3. Efficient Packet Forwarding ..............................13 67 6.4. Additional Prospects .....................................14 68 7. Security Considerations .......................................14 69 8. References ....................................................15 70 9. Acknowledgments ...............................................16 71 10. Authors' Addresses ............................................16 72 APPENDIX A. Alternative Solutions .................................16 73 APPENDIX B. Revised IPv6 Header ...................................19 75 1 Introduction 77 Today's RSVP implementations in routers suffer from the lack of flow 78 semantics within IPv4. However, the flow label provided with the new 79 Internet Protocol Version 6 enables these problems to be overcome. 81 We believe that the IPv6 standard is now mature enough for other 82 protocols to fully exploit its capabilities. In particular, the 83 specification of IPv6 flow label utilization in RSVP should be 84 completed. 86 The two main objectives of this memo are: firstly, to motivate 87 researchers and developers to adopt the flow label as an efficient 88 means of classifying packets, and secondly, since the use of the flow 89 label is only briefly described in the Version 1 specification of 90 RSVP, this memo aims to clearly specify how the flow label should be 91 used in RSVP. 93 The next section gives a description of the flow label and its 94 benefits in the context of resource reservation. Section 3 discusses 95 the problems facing present RSVP implementations in routers due to 96 the limitations of IPv4. Section 4 discusses the use of the flow 97 label as a packet classifier. Section 5 describes the required 98 extensions to the RSVP specification necessary for proper utilization 99 of the flow label. Section 6 lists the benefits of using the flow 100 label in RSVP. In Section 7, additional security considerations due 101 to the extensions are discussed. Appendix A presents four 102 alternative approaches for utilizing the flow label in RSVP. Appendix 103 B outlines the revised IPv6 header of the IPng working group along 104 with the discussion leading to the decision. 106 2 Description of the IPv6 Flow Label 108 When the designers of the next generation Internet protocol, IPv6, 109 included a 24 bit header field for a flow label, they were convinced 110 that the flow identifier was a promising extension to IP. 112 According to the IPv6 specification [RFC1883], the flow label field 113 might be used by a source to label packets which require special 114 handling by intervening IPv6 routers, such as non-default quality of 115 service (QoS) or "real-time" service. The idea was to use the flow 116 label field to label packets of a data flow with the same value. 117 Therefore, the definition of a "flow" comes implicitly from the 118 definition of the flow label itself. A flow is defined as a sequence 119 of packets sent from a particular source to the same (unicast or 120 multicast) destination for which the source desires special handling 121 by the intervening routers. The flow label is assigned to a flow by 122 the source or sending node. A source can never have more than one 123 flow with the same flow label at a given time. Based on this 124 definition, flows can be unambiguously distinguished by the 125 combination of the source IP address and a non-zero flow label. 126 Packets that do not belong to a flow must have their flow label set 127 to zero. 129 New flow labels must be chosen (pseudo-)randomly and uniformly. The 130 reason for the random allocation is to make any set of bits within 131 the flow label field suitable for use as a hash key by routers, for 132 looking up the state associated with the flow. As we will see later, 133 this feature has an important impact on the processing of flows 134 within RSVP implementations in routers. 136 A more detailed description of the general processing rules for the 137 IPv6 flow labels, not related to RSVP, can be read in the IPv6 138 specification. Additional information regarding the usage of the 139 IPv6 flow label field is presented in [RFC1809]. 141 Although the flow label field is 24 bits long according to the IPv6 142 specification, the IPng working group within the IETF has recently 143 agreed to reduce the flow label size to 20 bits. In Appendix B, we 144 present the revised IPv6 header and a brief summary of the 145 discussion. Further on in this memo, we implicitly assume a flow 146 label size of 20 bits, although this does not affect the mechanisms 147 described. 149 When the IPv6 designers decided to include a flow label in the new IP 150 header, they clearly had packet classification in mind. The routers 151 along the path between the source and destination use the flow label 152 to easily identify packets that are related and may need special 153 handling, such as QoS services. The type of service (TOS) field of 154 IPv4 or the Class field of IPv6 is also intended to be used as a 155 packet classifier [RFC791, RFC1349]. However, the latter is used to 156 classify packets with regard to different service classes, whereas 157 the former enables classification in terms of packet/flow 158 affiliation. 160 The addition of the flow label field provides the IP protocol with 161 the concept of a flow. As a result, routers are now capable of 162 managing and servicing flow specific QoS requirements based on IP 163 semantics only. 165 In the next section, we review how packet classification is achieved 166 in the context of RSVP for IPv4 and IPv6 when no notion of flows is 167 available. Besides the "layer violation problem", we address further 168 drawbacks regarding the lack of flow semantics. 170 3 The Layer Violation Problem 172 Routers along a reserved path are required to identify packets from 173 different data flows in order to process them according to their 174 desired QoS needs. However, since IPv4 does not directly support the 175 concept of flows, the intervening routers have to make use of 176 transport protocol or application level data to achieve proper packet 177 classification. 179 The fact that a router which is supposed to process data only at the 180 network layer, according to the OSI reference model, requires 181 information from the transport or application protocol to provide QoS 182 support within RSVP, introduces what we call the "layer violation 183 problem". 185 According to Version 1 of RSVP, routers with traffic control support 186 require a packet classifier responsible for identifying the QoS 187 parameters of incoming packets. Once a packet is classified, it is 188 handed over to the packet scheduler which processes it based on its 189 QoS requirements. The classification is done first, by determining 190 the session of a packet and second, by applying the filters of a 191 session. If the packet is matched by one of the filters, the 192 corresponding flowspec defines its QoS requirements. 194 A session in RSVP is defined by the triple: (DestAddress, ProtocolId 195 [, DstPort]). Here, DestAddress, the IP destination address of the 196 data packets, may be a unicast or multicast address. ProtocolId is 197 the IP protocol ID. The optional DstPort parameter is a "generalized 198 destination port", i.e., some further demultiplexing in the transport 199 or application protocol layer. In present implementations, the 200 DstPort is usually defined by the UDP or TCP destination port, since 201 UDP and TCP are the only widely deployed transport protocols on the 202 Internet at this time. 204 A filter spec is defined by the tuple (SrcAddress [, SrcPort]). Here 205 SrcAddress is the IP address of the sending host. The optional 206 SrcPort parameter is also a "generalized source port" that allows 207 further differentiation between flows from the same source address. 208 The SrcPort is usually defined by the UDP or TCP port of the sending 209 application. 211 By reviewing the classification process of the currently deployed 212 RSVP implementations, it is obvious that routers on IP networks must 213 look inside the IP payload to access the UDP or TCP ports within the 214 transport protocol header. This inherent layer violation is 215 necessary due to the lack of network level flow semantics within IPv4 216 and a result of not exploiting the flow label within RSVP for IPv6. 218 Layer violation has serious drawbacks for traffic control performance 219 in routers. Routers have to look inside every arriving packet for 220 any destination which has a RSVP session registered in order to 221 classify the packet, even if the packet does not belong to a reserved 222 flow. The issue here is that there is no support in IP for 223 distinguishing packets that belong to a flow and those that do not. 224 In the case of IPv4, accessing the transport protocol ports is not 225 too expensive; the IPv4 header explicitly defines the header length 226 allowing relatively easy access to the ports. However, in IPv6 this 227 can be a costly task, since all the extension headers need to be 228 skipped in order to get to the transport protocol header. 229 Furthermore, this performance loss increases the processing time of a 230 packet in each intervening router and, as a result, the end-to-end 231 delay which is the limiting factor in many real-time streaming 232 applications in the first place. 234 Another disadvantage caused by the dependency on transport or 235 application protocol information is that no IP-level security 236 mechanisms can be used in conjunction with RSVP. IP-level Security, 237 under either IPv4 or IPv6, may encrypt the entire transport header, 238 hiding the port numbers of data packets from intermediate routers. 239 In order to overcome this problem, an extension to RSVP for IP 240 security under IPv4 and IPv6 was defined in [RFC2207]. However, when 241 using RSVP with the IPv6 flow label, this extension will become 242 obsolete for IP-level security (see section 6.2 for further 243 discussion). 245 The lack of flow semantics in IPv4 forces RSVP routers to use "work 246 arounds", as described above, for proper classification of data 247 packets. However, in IPv6 networks, the "layer violation problem" 248 can be solved by deploying the flow label. The next section 249 discusses the advantages of this approach in detail. 251 4 The Flow Label as Packet Classifier 253 The flow label was added to the IPv6 header to extend the network 254 protocol to include the concept of flows supporting the management 255 and processing of data streams in the network. 257 According to [RFC1809], "real-time flows must obviously always have a 258 flow label, since flows are a primary reason flow labels were 259 created." Therefore, RSVP which is primarily used to support real- 260 time flows by reserving resources for them should not lack a clear 261 specification of how the flow label should be used. 263 The main purpose of using the flow label in RSVP is to properly set- 264 up packet classification in routers in order to improve its 265 efficiency. We will see that the properties of flow labels are ideal 266 for this task: 268 First, a flow label of zero indicates that a particular packet does 269 not belong to a flow. This allows routers to immediately identify 270 (by a simple check within the IPv6 header) whether a packet needs 271 special treatment due to QoS needs or not. 273 Second, the flow label in conjunction with the source IP address 274 uniquely identifies a flow. This is true because the IPv6 275 specification requires that each host ensures unique local flow 276 labels. The great benefit for packet classification is that all the 277 information needed to uniquely classify packets is available within 278 the IP header, where it should be. 280 Third, flow labels are chosen (pseudo-)randomly and uniformly, and 281 assigned to a flow by the flow's source node. The advantage of this 282 attribute is that any set of bits within the flow label field should 283 be suitable for use as a hash key by routers. This is extremely 284 valuable for use within RSVP, since routers along a reserved path 285 need to identify the session to which every packet belongs, and match 286 the filter spec in order to access the QoS parameters in the 287 flowspec. Hash table based access to this data can be performed very 288 efficiently by using a set of contiguous bits from the flow label as 289 a key. 291 In summary, utilization of the flow label simplifies the processing 292 of traffic control in routers and should greatly improve efficiency. 293 Nevertheless, there are still a number of open questions: 295 o How do routers deal with packets that carry a flow label that has 296 no locally defined state? 298 The default rule should be that if a router receives a datagram 299 with an unknown flow label, it treats the datagram as if the flow 300 label were zero. A general discussion on how to deal with this 301 situation in IPv6 networks is presented in [RFC1809]. 303 If we assume that the flow label is mainly used within the context 304 of RSVP, in a later version of RSVP a router could possibly 305 initialize a "local repair" by requesting a PATH message from the 306 last hop router upon receipt of a packet with an "unknown" flow 307 label. 309 o How do routers handle flows with equal flow labels? 311 In order for routers to deal with equal flow label values from 312 different flows, they must provide special support for such 313 "collisions". If the router uses a hash table for flow state 314 information, a sophisticated hash collision mechanism is required, 315 although such hash collisions are fairly unlikely if the hash key 316 is not too short. For example, when using 14 bits of the flow 317 label as a hash key, the probability of a collision in the local 318 flow state table is 1/(2^14) = 1/16384. 320 5 Implementation of the Flow Label 322 The objective of this section is to clearly specify how support for 323 the IPv6 flow label should be achieved within RSVP. It describes the 324 changes required to the Version 1 specification and explains 325 additional processing rules. In Appendix A, we present alternative 326 approaches that could be adopted for flow label processing with RSVP 327 along with our reasons for discarding them. 329 We decided on the following solution with a view to minimizing the 330 number of changes necessary to the original specification and 331 simplifying the implementation. 333 5.1 Object Definition 335 This approach does not require additional session or filter spec 336 objects. Rather than adding new objects to the protocol, we have 337 tried to reuse the original objects and simply extend them by adding 338 extra processing rules. 340 However, since the flow label size in the IPv6 header was revised by 341 the IPng working group of the IETF (see Appendix B for further 342 information), we decided to redefine the FILTER_SPEC object (Class 343 10) and the SENDER_TEMPLATE object (Class 11) with C-Type 3 of the 344 original specification. 346 Rather than defining new FILTER_SPEC and SENDER_TEMPLATE objects with 347 C-Type 4, we decided to redefine the objects since they are now 348 obsolete. 350 The revised filter spec object is shown here: 352 FILTER_SPEC object: Class = 10, C-Type = 3 353 +-------------+-------------+-------------+-------------+ 354 | | 355 + + 356 | | 357 + IPv6 SrcAddress (16 bytes) + 358 | | 359 + + 360 | | 361 +--------------------+------+-------------+-------------+ 362 | /////// | Flow Label (20 bits) | 363 +--------------------+------+-------------+-------------+ 365 The revised SENDER_TEMPLATE object has the same format. 367 When using RSVP with flow label support, the revised FILTER_SPEC and 368 SENDER_TEMPLATE objects must be used in PATH and RESV messages. 370 5.2 Processing Rules 372 Although the RESV and PATH message formats do not change, the 373 processing of these messages will require modification. 374 Specifically, the usage of the DstPort field in the SESSION object 375 must be revised. 377 According to the RSVP specification, a session is defined by the 378 triple: (DestAddress, protocol ID, DstPort). In present 379 implementations, the DstPort contains the UDP/TCP destination port, 380 specifically "a 16-bit quantity carried at the octet offset +2 in the 381 transport header or zero for protocols that lack the notion of 382 transport ports." In RSVP without flow label support, the 383 destination port is needed to differentiate flows from the same 384 source IP address and port sent to the same destination IP address. 385 However, since this requirement becomes obsolete when using the flow 386 label, we set the DstPort in the SESSION object to zero. By doing 387 this we implicitly limit the number of sessions per IP address to 388 one, but, since sender applications choose unique flow labels for all 389 local flows, individual flow reservations can still be unambiguously 390 distinguished based on the destination IP address in the SESSION 391 object and the FILTER_SPEC (source IP address and flow label). 393 5.3 Reservation Styles 395 The extended processing rules, as described above, have some 396 ramifications depending upon the reservation style, namely the 397 Fixed-Filter (FF), Shared Explicit (SE), or Wildcard-Filter (WF). 399 5.3.1 Explicit Sender Selection 401 The FF and SE styles have an explicit sender selection. Therefore, 402 the FILTER_SPEC object contains the (SrcAddress, FlowLabel) pair. 403 This allows the receiver to uniquely identify senders based on both 404 elements of the pair. When merging explicit sender descriptors, the 405 senders may only be considered identical when both elements are 406 equal. 408 5.3.2 Wildcard Sender Selection 410 In a WF style reservation, the RESV message does NOT contain a 411 FILTER_SPEC since it would be superfluous to specify senders 412 explicitly in a "shared" reservation with "wildcard" sender 413 selection. As a result, classifiers may match all packets which 414 contain both the session's destination IP address and protocol ID to 415 such WF reservations. Note, according to the processing rules 416 defined above, we do not make use of the destination port to identify 417 different sessions in order to avoid layer violation problems. 418 Therefore, when using WF style reservations, all flows to the same IP 419 destination address using the same IP protocol ID will share the same 420 reservation. 422 A solution for this limitation is not proposed at this time. This 423 issue is not seen as significant since the flow label improves packet 424 classification only with respect to reservations based on explicit 425 sender selection. 427 As a result, when multiple WF style reservations for a particular 428 destination are needed, the flow label extension as described in this 429 note can not be applied at this stage. However, there is no 430 restriction of using the RSVP without flow label support as described 431 in the Version 1 specification in complement. The consequence is less 432 efficient QoS support due to layer violations. 434 5.4 Packet Classification 436 Besides the changes necessary to the protocol processing rules, the 437 packet classifier also needs to be adapted to make the most of the 438 flow label. These changes are the most promising of all, since the 439 flow label allows a significant reduction in the processing cost per 440 packet seen by routers. 442 In order to enable the packet classifier to access state information 443 of active flows with minimal processing cost, it is important that 444 local hash tables or databases of flows are indexed by means of the 445 flow label. This modification is essential as the classification of 446 data packets is primarily based on the flow label when it is non- 447 zero. 449 During the transition period, routers will need mechanisms to provide 450 fast access to flow state information based on the IP address and 451 port, as well as new mechanisms based on the flow label. 453 6 Benefits of Using the Flow Label 455 In this section, we explore the benefits of adopting the flow label 456 for IPv6 based RSVP use. 458 The most important advantage arising from flow label utilization is 459 that it allows RSVP to be implemented without recourse to 460 "clandestine" techniques. Due to the flow semantics of IPv6, the 461 implicit "layer violation problem" is resolvable. As shown in 462 section 5, routers no longer depend on transport or application level 463 protocols to correctly classify packets. 465 The next two subsections discuss advantages directly related to the 466 avoidance of layer violation. In section 6.3 and 6.4, we present 467 additional benefits of the flow label approach. 469 6.1 Efficient Packet Classification 471 In order to show that packet classification based on the flow label 472 improves efficiency, we need some form of measurement to compute the 473 processing cost of packet classification in routers in order to 474 compare the different approaches. 476 For the purpose of illustration, we use a simplified model of the 477 packet classifier which processes packets purely in software. By 478 looking at the operations necessary to classify packets for both 479 approaches, namely IPv4/IPv6 RSVP without flow label support and IPv6 480 RSVP with flow label support, we try to show the complexity decrease 481 and efficiency improvement of the flow label utilization. 483 In general, packet classification in routers is done first by 484 identifying the session of a packet and second by matching a packet 485 against the filters of the corresponding session. 487 Without support for flow labels, packet classification requires the 488 following steps: First, the classifier needs to check whether the 489 packet destination IP address belongs to a session. This address 490 lookup could be done by means of hashing. In order to achieve better 491 hashing results, a hash key based on the IP address might have to be 492 computed first. Second, in the case of a hash hit, the DstPort needs 493 to be compared with the session description. This port comparison, 494 which is an inherent layer violation, and therefore costly 495 (especially for IPv6), must be performed frequently if multiple 496 sessions are active for a particular destination node. Third, if the 497 port is identical, a check for the correct protocol ID is required. 498 This test is performed last since it is likely that the second test 499 fails first due to the unsuited distribution of port numbers 500 (individual applications use usually the same ports). After the 501 identification of the packet's session, the filter spec must be 502 matched. This is done by searching a list of filters associated with 503 the session. In order to find the correct filter, the fourth step, 504 comparing the source IP address, needs to be performed. And finally, 505 if it matches any of the filter's addresses, the source port must be 506 checked. This is also very likely, if we assume that sessions have 507 multiple flows, for example one for audio and one for video. 509 A serious problem in this approach is the inability to identify 510 whether a packet belongs to a flow that requires special handling or 511 not without performing the expensive classification first. 513 Packet classification based on the IPv6 flow label has important 514 advantages over the former approach. As already mentioned in section 515 4, the flow label can be used to immediately identify whether packets 516 belong to a flow or not. 518 Another advantage arising from the flow label property that they are 519 (pseudo-)randomly assigned is: the flow label or any set of bits 520 within the flow label field can be used as a hash key. No additional 521 cost due to hash key generation is incurred. Furthermore, since the 522 flow label is (pseudo-)randomly selected, it is most likely a 523 "better" hash key than a hash key generated from the source address 524 in the sense that it causes less hash collisions and, as a result, 525 less processing costs for classification. 527 In the case of packet classification with flow label support, the 528 processing required in the router is much simpler: First, the flow 529 label is used as a hash key to look up whether flow state exists for 530 a packet. In the case of a hash hit, it is most likely that the 531 correct flow state entry is directly identified due to the random 532 generation of flow labels. However, to make sure it is not a 533 collided hash entry, the destination IP address must be compared in a 534 second step. Third, if the destination address is equal to the IP 535 address in the session description, the protocol ID must be checked. 536 And finally, the source IP address needs to be matched against the 537 filter spec address. 539 Even without exploring the exact costs for each of the operations 540 described above, and the actual probability that packets belong to a 541 session or flow, it seems clear that the processing efficiency of 542 packet classification with flow label is a significant improvement 543 over that currently exploited by RSVP. A more detailed analysis with 544 numerical results is given in [Schmid98]. 546 The main reason for the efficiency gain of the latter approach lies 547 in the fact that flow state information can be indexed with the flow 548 label as an identifier instead of using a key based on destination IP 549 addresses and the avoidance of layer violating operations. 551 The performance comparison given here is based on a software 552 processing model. One could easily argue that this does not hold if 553 these operations are processed in hardware or with hardware support 554 as in real routers. However, even then, the analysis still gives 555 insights about the complexity of the required operations and, 556 therefore, provides information about possible hardware 557 implementation costs. 559 6.2 Enabling Network Layer Security Mechanisms 561 Network layer security in the currently deployed Internet is usually 562 achieved using IP security, or IPSEC, protocols [RFC1825] such as 563 packet level authentication [RFC1826] and integrity and 564 confidentiality [RFC1827]. The IPSEC extensions provide service by 565 adding new headers, namely the Authentication Header (AH) and/or 566 Encapsulating Security Payload (ESP), between the IP header and the 567 transport protocol header. 569 When using the IPSEC protocol within RSVP, first, access to the 570 transport protocol ports requires modifications in the case of IPv4 571 and second, transport ports might be hidden from intervening routers 572 when encryption is used. Therefore, security mechanisms within 573 Version 1 of RSVP are only applicable on a per host, rather than a 574 per flow basis. 576 Hence, RSVP Extensions for IPSEC were defined in [RFC2207] so that 577 data flows containing IPSEC protocols can be controlled at a 578 granularity similar to that already specified for UDP and TCP. The 579 RSVP extension proposes the usage of the IPSEC Security Parameter 580 Index, or SPI, in place of the UDP/TCP-like ports. The announcement 581 of flow specific SPIs for the intermediate RSVP routers nodes 582 requires a new FILTER_SPEC and SESSION object which includes the 583 IPSEC SPI. 585 However, in IPv6 RSVP, the flow label can be used directly as an 586 identifier to distinguish multiple flows from a source address to the 587 same destination. The advantage of using the flow label to 588 demultiplex flows is that the flow label field of the IPv6 header is 589 not encrypted by any network level security mechanism and, therefore, 590 it can easily be used for packet classification in conjunction with 591 IPSEC by the routers along a reserved path. 593 As a result, when using RSVP with flow label support, the IPSEC 594 extensions for RSVP become obsolete. 596 6.3 Efficient Packet Forwarding 598 The IP packet forwarding process of routers is computationally 599 expensive when options (in IPv4) or extension headers (IPv6) need to 600 be processed. Each packet carrying such additional routing 601 information increases the processing load and the end-to-end delay. 603 According to the IPv6 specification, all datagrams with the same 604 (non-zero) flow label must have the same destination address, Hop- 605 by-Hop options header (excluding the Next Header field), Routing 606 header and source address contents. As a result, by using the flow 607 label, the IP packet forwarding can be performed more efficiently. 608 Simply by looking up the flow label in a flow information table, the 609 router can decide how to route and forward the datagram without 610 examining the rest of the header. Therefore, the expensive options 611 or extension header processing must not be done on a per packet 612 basis. 614 In summary, use of the flow label within RSVP allows simplification 615 and improvement of the standard IP packet forwarding task. 617 6.4 Additional Prospects of the Flow Label 619 Utilizing the flow label within resource reservation protocols such 620 as RSVP for real-time data streaming has, besides the advantages 621 mentioned above, additional potential. 623 Reserving resources by means of the flow label could solve or at 624 least reduce problems caused by frequent route changes, e.g. route 625 "flapping". Route changes without a good reason, i.e. a link going 626 down, is dangerous for data streams with strict QoS requirements. 627 While a flow might have resources reserved for its data stream on one 628 path, it could lose its QoS reservations when the routing protocol 629 suddenly decides to use a different route. The fact that RSVP makes 630 use of standard network level routing protocols provides it with 631 sophisticated error recovery mechanisms. This is certainly one of 632 the valuable features of RSVP, however, if a route is changed for 633 reasons not related to error recovery, data streams suffer from 634 temporary QoS breakdown due to lost resources. In the worst case it 635 could happen that after a route change the QoS requirements cannot be 636 satisfied due to the lack of resources on the new link. 638 The flow semantics of IPv6 has the potential to allow relatively 639 simple implementation of mechanisms supporting route "pinning", which 640 prevents arbitrary route changes, but still allows route changes if 641 an error occurs. For example, the flow label could be used to 642 prevent QoS sensitive streams from being affected from route changes 643 due to load balancing. 645 In addition, ongoing research in the area of label switching proposes 646 approaches that make use of IPv6 flow labels to identify the 647 appropriate reservation state of RSVP for a packet based on its label 648 value. Thus, the packet is switched with respect to its reservation 649 state. The Internet Draft [Davie98] suggests a way to distribute 650 label bindings using RSVP messages by introducing a new RSVP object 651 RSVP_LABEL to carry a label in an RSVP message. 653 7 Security Considerations 655 Since the adoption of the flow label to RSVP as described in this 656 note does not introduce new data fields, besides the flow label, and 657 does not require additional messages, we can apply the security 658 considerations stated in [RFC2205] to this note. 660 In addition, the flow label represents another data element about the 661 IP flow that might be available to an adversary. The label values 662 might be useful to an adversary engaging in traffic analysis by 663 monitoring not only the data packets of the IP flow but also the RSVP 664 control messages associated with the flow. One possible approach to 665 prevent such attacks would be the deployment and the use of 666 appropriate link-layer encryption mechanisms. However, protection 667 against traffic analysis attacks is outside the scope of this memo. 669 8 References 671 [Davie98] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., 672 Srinivasan, V., and Blake, S., "Use of Label Switching 673 With RSVP", IETF Internet-Draft (work in progress), 674 draft-ietf-mpls-rsvp-00.txt, March 1998 676 [Hinden97] Hinden, B., "Minutes of the IETF IPng Working Group 677 Meeting in Munich", August 1997, online at: 678 http://www.cs-ipv6.lancs.ac.uk/ipv6/documents/standards/ 679 general-comms/ietf/ipngwg/ ipngwg-minutes-97aug.txt 681 [Schmid98] Schmid, S., Scott, A., Hutchison, D., and Froitzheim, K., 682 "QoS based Real Time Audio Streaming in IPv6 Networks", 683 VV98, Proceedings of SPIE Vol. 3529, Internet Routing and 684 Quality of Service, Boston, 1998 686 [RFC791] Postel, J., "Internet Protocol", RFC 791, DARPA, 687 September 1981. 689 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 690 Suite". RFC 1349, July 1992. 692 [RFC1809] Partridge, C.,"Using the Flow Label Field in IPv6" 693 RFC 1809, June 1995. 695 [RFC1825] Atkinson, R., "Security Architecture for the Internet 696 Protocol", RFC 1825, NRL, August 1995. 698 [RFC1883] Deering, S. and Hinden, R., "Internet Protocol, Version 6 699 (IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon 700 Networks, December 1995. 702 [RFC2205] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., 703 and S. Jamin, "Resource ReSerVation Protocol (RSVP) 704 -- Version 1 Functional Specification", RFC 2205, 705 September 1997. 707 [RFC2207] Berger, L. and O'Malley, T., "RSVP Extensions for IPSEC 708 Data Flows", RFC 2207, September 1997. 710 [RFC2209] Braden, R., Ed., Zhang, "Resource ReSerVation 711 Protocol (RSVP) -- Version 1 Message Processing 712 Rules", RFC 2209, September 1997. 714 9 Acknowledgments 716 The work presented in this memo was done within CoBrow - a research 717 project funded in parts by the European Community under the 718 Telematics Applications Program and the Swiss Federal Office of 719 Science and Education. The authors would like to acknowledge 720 contributions from Nick Race and Martin 721 Dunmore who did some early implementation 722 extensions to the ISI RSVP daemon rel4.2a2. Special appreciation goes 723 to Joe Finney and Laurent Mathy 724 for their editorial and technical 725 comments. 727 10 Authors' Addresses 729 Stefan Schmid Dr. Andrew Scott 730 Distributed Multimedia RG Distributed Multimedia RG 731 Computing Department Computing Department 732 Lancaster University Lancaster University 733 Lancaster LA1 4YR Lancaster LA1 4YR 734 United Kingdom United Kingdom 735 Phone: (+44) 7970 419935 Phone: (+44) 1524 65201 736 EMail: sschmid@comp.lancs.ac.uk EMail: acs@comp.lancs.ac.uk 738 A Alternative Solutions 740 This Appendix presents four alternative solutions for implementing 741 IPv6 flow label support within RSVP. We describe each of these 742 approaches briefly and discuss their advantages and disadvantages 743 together with the reasons why we rejected them. 745 A.1 Use DstPort in SESSION Object 747 In this first approach, the DstPort in the SESSION object is used as 748 defined in the RSVP specification. Thus, the DstPort is used in 749 conjunction with the destination IP address to identify sessions. 750 However, since our main concern is the "layer violation problem" 751 caused by the classification of packets based on transport level 752 data, we would have to abstain from using the destination port for 753 packet classification. As a result, this approach suggests to use the 754 DstPort of the SESSION object to "manage" RSVP sessions in the 755 routers along a reserved path, but refuses to use the DstPort to 756 classify the packets. 758 The advantages of this approach is that we change the notion of 759 sessions only with respect to packet classification. Routers can 760 still manage multiple sessions for one destination host. The reason 761 for rejecting this approach is: why should the destination port be 762 specified in the session object if it is used only for administration 763 reasons without any gain for resource reservation and packet 764 classification. 766 A.2 Specification of a new SESSION Object 768 This approach suggests a new SESSION object (presented below) which 769 is capable of carrying the flow label to intervening routers. 771 Instead of using the DstPort as a session demultiplexer, the flow 772 label would be used for that purpose. The flow label size demands 773 the definition of a new session object since its 20 bits cannot be 774 squeezed in the 16 bit DstPort field. 776 The advantages of using the flow label as part of the SESSION object 777 is that the session concept would hardly be affected with the 778 exception of using the flow label to distinguish multiple sessions to 779 the same destination node. The drawbacks are that a new object is 780 required. As a result, the protocol becomes unnecessarily complex 781 and significant changes to the current implementations are required 782 due to the different size of the revised session object. 784 IPv6/UDP SESSION object: Class = 1, C-Type = 3 785 +-------------+-------------+-------------+-------------+ 786 | | 787 + + 788 | | 789 + IPv6 DestAddress (16 bytes) + 790 | | 791 + + 792 | | 793 +-------------+-------------+-------------+-------------+ 794 | Protocol Id | Flags | DstPort | 795 +-------------+-------------+-------------+-------------+ 796 | /////// | Flow Label (20 bits) | 797 +-------------+-------------+-------------+-------------+ 799 A.3 Use Lower 16 Bit of Flow Label in SESSION Object 801 This alternative approach, reuses the original SESSION object by 802 changing the DstPort field to a FlowLabel field (see below). As a 803 result, the advantages of the last two approaches, namely that 804 multiple sessions to the same destination host can be differentiated, 805 would be valid as well. This would be an easy solution with respect 806 to the number of changes necessary to the original specification. 808 However, since the flow label is larger than the destination port by 809 4 bits, only a subset of the bits could be used. The problem arising 810 from cutting off four bits of the flow label is that unresolvable 811 collisions might occur. Although it is very unlikely that a source 812 host selects two flow labels with the same 16 lower order bits 813 (2^4/2^20 = 1/65536), there would be no chance for routers to resolve 814 them. Such a collision would cause a restriction of a single 815 reservation for multiple flows. 817 IPv6/UDP SESSION object: Class = 1, C-Type = 3 818 +-------------+-------------+-------------+-------------+ 819 | | 820 + + 821 | | 822 + IPv6 DestAddress (16 bytes) + 823 | | 824 + + 825 | | 826 +-------------+-------------+-------------+-------------+ 827 | Protocol Id | Flags | Flow Label (lower 16 bit) | 828 +-------------+-------------+-------------+-------------+ 830 A.4 Redefine Flag Field of SESSION Object 832 Our last alternative approach suggests to redefine the flag field in 833 the SESSION object to a size of 4 bits. The 4 bits gained in 834 conjunction with the 16 bits of the DstPort could form a new flow 835 label field (see below). Since the flag field is hardly used - only 836 the flag E_Police = 0x01 is defined so far - this should not be a 837 significant problem at this time. 839 The reason for rejecting this approach is that fundamental changes to 840 the original specification, and modifications of current 841 implementations would be required. 843 IPv6/UDP SESSION object: Class = 1, C-Type = 3 844 +-------------+-------------+-------------+-------------+ 845 | | 846 + + 847 | | 848 + IPv6 DestAddress (16 bytes) + 849 | | 850 + + 851 | | 852 +-------------+-------------+-------------+-------------+ 853 | Protocol Id | Flags| Flow Label (20 bits) | 854 +-------------+-------------+-------------+-------------+ 856 B Revised IPv6 Header 858 In the meeting of the IETF in Munich in August 1997, the IPng working 859 group agreed to redefine the priority and flow label field 860 [Hinden97]. 862 The Priority field is renamed in a "Class" field and its length is 863 enlarged to eight bits. The fact that a change to the priority 864 semantics took place (relative priorities were discarded) due to open 865 loop transmission problems, and the need for more control bits to 866 improve the congestion avoidance algorithm of RED, led the working 867 group to the decision to revise the priority field. 869 As a result of the increased length of the "Class" field, the flow 870 label field was reduced to 20 bits. The leading four octets of the 871 revised IPv6 header are presented here: 873 4 8 20 874 +-----+----------+---------------------------------------+ 875 | Ver | Class | Flow Label | 876 +-----+----------+---------------------------------------+