idnits 2.17.1 draft-schmid-rsvp-fl-01.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 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. ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2205]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 353: '... IPv6 flow label SHOULD be used within...' RFC 2119 keyword, line 395: '...TEMPLATE objects MUST be used in PATH ...' RFC 2119 keyword, line 444: '... network MUST verify the proper use ...' RFC 2119 keyword, line 447: '... greater than zero MUST be used. Upon...' 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 685, but not defined ** Obsolete undefined reference: RFC 1826 (Obsoleted by RFC 2402) == Missing Reference: 'RFC1827' is mentioned on line 686, but not defined ** Obsolete undefined reference: RFC 1827 (Obsoleted by RFC 2406) == Missing Reference: 'RFC1889' is mentioned on line 989, but not defined ** Obsolete undefined reference: RFC 1889 (Obsoleted by RFC 3550) == Unused Reference: 'RFC2209' is defined on line 849, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Braden94' -- Possible downref: Normative reference to a draft: ref. 'Davie98' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec-v2 is -01, but you're referring to -02. -- Possible downref: Non-RFC (?) normative reference: ref. 'Hinden97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Race98' ** 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schmid98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Zhang95' Summary: 19 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Stefan Schmid 2 Internet Draft Martin Dunmore 3 Document: draft-schmid-rsvp-fl-01.txt Nicholas Race 4 Expires February 1999 Andrew Scott 5 Lancaster University, UK 6 August 1998 8 RSVP Extensions for IPv6 Flow Label Support 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 This document suggests a proposed protocol for the Internet 29 community, and requests discussion and suggestions for improvements. 30 Distribution of this draft is unlimited. 32 Abstract 34 This document is an addendum to Version 1 of RSVP (Resource 35 ReSerVation Protocol) as defined in the proposed standard [RFC2205]. 36 The flow label, one of the new header fields of the IPv6 protocol, 37 allows improvements to resource reservation protocols on IPv6 capable 38 networks. Utilization of the flow label simplifies packet 39 classification and optimizes packet processing in routers along the 40 transport path. 42 The main objectives of this document are to specify the proper usage 43 of the IPv6 flow label and to promote its support within RSVP. This 44 memo defines extensions required to the Version 1 specification and 45 additional processing rules needed to ensure correct operation. 47 Rather than simply presenting the specification with no 48 justification, we have tried to present the benefits of adopting the 49 flow label within RSVP for IPv6. This addendum does not have any 50 effect on the implementation or usage of RSVP for IPv4. 52 Table of Contents 54 1. Introduction .................................................. 2 55 2. Description of the IPv6 Flow Label ............................ 3 56 3. The Layer Violation Problem ................................... 4 57 4. The Flow Label as Packet Classifier ........................... 6 58 5. Implementation of the Flow Label .............................. 8 59 5.1. Recommendation ........................................... 8 60 5.2. Object Definition ........................................ 8 61 5.3. Processing Rules ......................................... 9 62 5.4. Reservation Styles .......................................10 63 5.4.1. Explicit Sender Selection ..............................10 64 5.4.2. Wildcard Sender Selection ..............................11 65 5.5. Packet Classification ....................................12 66 6. Benefits of Using the Flow Label ..............................13 67 6.1. Efficient Packet Classification ..........................13 68 6.2. Enabling Network Layer Security Mechanisms ...............15 69 6.3. Efficient Packet Forwarding ..............................16 70 6.4. Additional Prospects .....................................16 71 7. Security Considerations .......................................17 72 8. References ....................................................17 73 9. Acknowledgments ...............................................19 74 10. Authors' Addresses ............................................19 75 APPENDIX A. Alternative Solutions .................................20 76 APPENDIX B. Revised IPv6 Header ...................................22 78 1 Introduction 80 Today's RSVP implementations in routers suffer from the lack of flow 81 semantics within IPv4. However, the flow label provided with the new 82 Internet Protocol Version 6 enables these problems to be overcome. 84 We believe that the IPv6 standard is now mature enough for other 85 protocols to fully exploit its capabilities. In particular, the 86 specification of IPv6 flow label utilization in RSVP should be 87 completed. 89 The two main objectives of this memo are: firstly, to motivate 90 researchers and developers to adopt the flow label as an efficient 91 means of classifying packets, and secondly, since the use of the flow 92 label is only briefly described in the Version 1 specification of 93 RSVP, this memo aims to clearly specify how the flow label should be 94 used in RSVP. 96 The next section gives a description of the flow label and its 97 benefits in the context of resource reservation. Section 3 discusses 98 the problems facing present RSVP implementations in routers due to 99 the limitations of IPv4. Section 4 discusses the use of the flow 100 label as a packet classifier. Section 5 describes the required 101 extensions to the RSVP specification necessary for proper utilization 102 of the flow label. Section 6 lists the benefits of using the flow 103 label in RSVP. In Section 7, additional security considerations due 104 to the extensions are discussed. Appendix A describes alternative 105 approaches to the solutions presented throughout this memo. Appendix 106 B outlines the revised IPv6 header of the IPng working group along 107 with the discussion leading to the decision. 109 2 Description of the IPv6 Flow Label 111 When the designers of the next generation Internet protocol, IPv6, 112 included a 24 bit header field for a flow label, they were convinced 113 that the flow identifier was a promising extension to IP. 115 According to the IPv6 specification [RFC1883], the flow label field 116 might be used by a source to label packets which require special 117 handling by intervening IPv6 routers, such as non-default quality of 118 service (QoS) or "real-time" service. The idea was to use the flow 119 label field to label packets of a data flow with the same value. 120 Therefore, the definition of a "flow" comes implicitly from the 121 definition of the flow label itself. A flow is defined as a sequence 122 of packets sent from a particular source to the same (unicast or 123 multicast) destination for which the source desires special handling 124 by the intervening routers. 126 The flow label is assigned to a flow by the source or sending node. 127 A source can never have more than one flow with the same flow label 128 at a given time. A discussion on how to ensure unique local flow 129 labels is presented in [Deerin98]. Based on this definition, flows 130 can be unambiguously distinguished by the combination of the source 131 IP address and a non-zero flow label. Packets that do not belong to 132 a flow must have their flow label set to zero. 134 New flow labels must be chosen (pseudo-)randomly and uniformly. The 135 reason for the random allocation is to make any set of bits within 136 the flow label field suitable for use as a hash key by routers for 137 looking up the state associated with a flow. As we will see later, 138 this feature has an important impact on the processing of flows 139 within RSVP implementations in routers. 141 A more detailed description of the general processing rules for the 142 IPv6 flow labels, not related to RSVP, can be read in the IPv6 143 specification. Additional information regarding the usage of the 144 IPv6 flow label field is presented in [RFC1809]. 146 Although the flow label field is 24 bits long according to the IPv6 147 specification, the IPng working group within the IETF has recently 148 agreed to reduce the flow label size to 20 bits. In Appendix B, we 149 present the revised IPv6 header and a brief summary of the 150 discussion. Further on in this memo, we implicitly assume a flow 151 label size of 20 bits, although this does not affect the mechanisms 152 described. 154 When the IPv6 designers decided to include a flow label in the new IP 155 header, they clearly had packet classification in mind. The routers 156 along the path between the source and destination use the flow label 157 to easily identify packets that are related and may need special 158 handling, such as QoS services. The type of service (TOS) field of 159 IPv4 or the Class field of IPv6 is also intended to be used as a 160 packet classifier [RFC791, RFC1349]. However, the latter is used to 161 classify packets with regard to different service classes, whereas 162 the former enables classification in terms of packet/flow 163 affiliation. 165 The addition of the flow label field provides the IP protocol with 166 the concept of a flow. As a result, RSVP routers are now capable of 167 classifying packets and mapping their flow specific QoS requirements 168 based on IP semantics only. 170 In the next section, we review how packet classification is achieved 171 in the context of RSVP for IPv4 and IPv6 when no notion of flows is 172 available. Besides the "layer violation problem", we address further 173 drawbacks regarding the lack of flow semantics. 175 3 The Layer Violation Problem 177 Routers along a reserved path are required to identify packets from 178 different data flows in order to process them according to their 179 desired QoS needs. However, since IPv4 does not directly support the 180 concept of flows, intervening routers have to make use of transport 181 protocol or application level data to achieve proper packet 182 classification. 184 The fact that a router which is supposed to process data only at the 185 network layer, according to the OSI reference model, requires 186 information from the transport or application protocol to provide QoS 187 support within RSVP, introduces what is known as the "layer violation 188 problem" [Zhang95]. 190 According to Version 1 of RSVP, routers with traffic control support 191 require a packet classifier responsible for identifying the QoS 192 parameters of incoming packets. Once a packet is classified, it is 193 handed over to the packet scheduler which processes it based on its 194 QoS requirements. The classification is achieved by determining a 195 packet's session and applying the filters of the session. If the 196 packet could be identified as belonging to one of the locally 197 registered flows, the corresponding flowspec defines its QoS 198 requirements. 200 A session in RSVP is defined by the triple: (DestAddress, ProtocolId 201 [, DstPort]). Here, DestAddress, the IP destination address of the 202 data packets, may be a unicast or multicast address. ProtocolId is 203 the IP protocol ID. The optional DstPort parameter is a "generalized 204 destination port", i.e., some further demultiplexing in the transport 205 or application protocol layer. In present implementations, the 206 DstPort is usually defined by the UDP or TCP destination port, since 207 UDP and TCP are the only widely deployed transport protocols on the 208 Internet at this time. 210 A filter spec is defined by the tuple (SrcAddress [, SrcPort]). Here 211 SrcAddress is the IP address of the sending host. The optional 212 SrcPort parameter is also a "generalized source port" that allows 213 further differentiation between flows from the same source address. 214 The SrcPort is usually defined by the UDP or TCP port of the sending 215 application. 217 By reviewing the classification process of currently deployed RSVP 218 implementations, it is obvious that routers on IP networks must look 219 inside the IP payload to access the UDP or TCP ports within the 220 transport protocol header. This inherent layer violation is 221 necessary due to the lack of network level flow semantics within IPv4 222 and a result of not exploiting the flow label within RSVP for IPv6. 224 Layer violation has serious drawbacks for traffic control performance 225 in routers. Routers have to look inside every arriving packet for 226 any destination which has a RSVP session registered in order to 227 classify the packet, even if the packet does not belong to a reserved 228 flow. The issue here is that, aside from the IPv6 flow label, there 229 is no support in IP for distinguishing packets that belong to a flow 230 and those that do not. In the case of IPv4, accessing the transport 231 protocol ports is not too expensive; the IPv4 header explicitly 232 defines the header length allowing relatively easy access to the 233 ports. However, in IPv6 this can be a costly task, since all the 234 extension headers need to be skipped in order to get to the transport 235 protocol header. Furthermore, this performance loss increases the 236 processing time of a packet in each intervening router and, as a 237 result, the end-to-end delay which is the limiting factor in many 238 real-time streaming applications in the first place. 240 Another disadvantage caused by the dependency on transport or 241 application protocol information is that no IP-level security 242 mechanisms can be used in conjunction with RSVP. IP-level Security, 243 under either IPv4 or IPv6, may encrypt the entire transport header, 244 hiding the port numbers of data packets from intermediate routers. 245 In order to overcome this problem, an extension to RSVP for IP 246 security under IPv4 and IPv6 was defined in [RFC2207]. However, when 247 using RSVP with the IPv6 flow label, this extension will become 248 obsolete for IP-level security (see section 6.2 for further 249 discussion). 251 The lack of flow semantics in IPv4 forces RSVP routers to use "work 252 arounds", as described above, for proper classification of data 253 packets. However, in IPv6 networks, the "layer violation problem" 254 can be solved by deploying the flow label. The next section 255 discusses the advantages of using the flow label as a packet 256 classifier. 258 4 The Flow Label as Packet Classifier 260 The flow label was added to the IPv6 header to extend the network 261 protocol to include the concept of flows supporting the management 262 and processing of data streams in the network. 264 According to [RFC1809], "real-time flows must obviously always have a 265 flow label, since flows are a primary reason flow labels were 266 created." Therefore, RSVP which is primarily used to support real- 267 time flows by reserving resources for them should not lack a clear 268 specification of how the flow label should be used. 270 The main purpose of using the flow label in RSVP is to properly set- 271 up packet classification in routers in order to improve its 272 efficiency. We will see that the properties of flow labels are ideal 273 for this task: 275 First, a flow label of zero indicates that a particular packet does 276 not belong to a flow. This allows routers to immediately identify 277 (by a simple check within the IPv6 header) whether a packet needs 278 special treatment due to specific QoS requirements or not. However, 279 this benefit can only be fully exploited if the flow label is 280 consistently used within RSVP for IPv6. As a result, we highly 281 recommend the mandatory use of the flow label within RSVP for IPv6. 283 Second, the flow label in conjunction with the source IP address 284 uniquely identifies a flow. This is true because the IPv6 285 specification requires that each host ensures unique local flow 286 labels. The great benefit for packet classification is that all the 287 information needed to uniquely classify packets is available within 288 the IP header, where it should be. 290 Third, flow labels are chosen (pseudo-)randomly and uniformly, and 291 assigned to a flow by the flow's source node. The advantage of this 292 attribute is that any set of bits within the flow label field should 293 be suitable for use as a hash key by routers. This is extremely 294 valuable for use within RSVP, since routers along a reserved path 295 need to identify the session to which every packet belongs, and match 296 the filter spec in order to access the QoS parameters in the 297 flowspec. Hash table based access to this data can be performed very 298 efficiently by using a set of contiguous bits from the flow label as 299 a key. 301 In summary, utilization of the flow label simplifies the processing 302 of traffic control in routers and should greatly improve efficiency. 303 Nevertheless, there are still a number of open questions: 305 o How do routers deal with packets that carry a flow label that has 306 no locally defined state? 308 The default rule should be that if a router receives a datagram 309 with an unknown flow label, it treats the datagram as if the flow 310 label were zero [RFC1809]. The implications for RSVP are that any 311 packet with an "unknown" flow label is forwarded in the same way 312 as normal best-effort traffic. These packets are treated in the 313 same manner as if they would not belong to a flow. 315 o How do routers handle flows with equal flow labels? 317 In theory, flows with equal flow labels do not cause problems since 318 flows are uniquely identified by the pair (source IP address, 319 flow label). However, when taking full advantage of the flow label 320 properties, namely uniqueness and randomness, it might be more 321 efficient to hash only on the flow label or any set of bits within 322 the flow label field. In the case of a hash collision, the source 323 IP address is used to unambiguously distinguish the flows. 324 Nevertheless, hash collisions based on the randomly distributed 325 flow label are fairly unlikely if the hash key is not too short. 326 For example, when using 14 bits of the flow label as a hash key, 327 the probability of a collision in the local flow state table is 328 1/(2^14) = 1/16384. 330 5 Implementation of the Flow Label 332 The objective of this section is to clearly specify how support for 333 the IPv6 flow label should be achieved within RSVP. It describes the 334 changes required to the Version 1 specification and explains 335 additional processing rules. In Appendix A, we present alternative 336 approaches that could be adopted for flow label processing within 337 RSVP along with our reasons for discarding them. 339 We decided on the following solution since we believe that this is 340 the most elegant way to define the usage of the IPv6 flow label 341 within RSVP. As we will see, the number of changes required to the 342 original specification is minimal and the implementations are simple. 344 5.1 Recommendation 346 The analysis of the IPv6 flow label properties in section 4 has shown 347 that the usage of the flow label within RSVP has provision to greatly 348 improve the packet classification processing. Section 6 explores 349 additional benefits of flow label use. Thus, in order to fully 350 exploit their advantages, it is important that flow labels are 351 consistently used within RSVP for IPv6 to classify packets. 353 As a result, the IPv6 flow label SHOULD be used within RSVP for IPv6. 354 Furthermore, we highly recommend that any future standards define 355 usage of the flow label to be mandatory. 357 We do not suggest that use of the flow label should be compulsory at 358 this stage, since there are still IPv6 implementations that do not 359 properly support flow label usage. Since the changes required to 360 enable flow label usage are minor, we believe that as soon as 361 applications and protocols, i.e. RSVP, make use of the flow label, IP 362 software developers and vendors will upgrade their releases. 364 5.2 Object Definition 366 This approach does not require additional session or filter spec 367 objects. Rather than adding new objects to the protocol, we have 368 tried to reuse the objects already defined and simply extend them by 369 adding extra processing rules. 371 However, since the flow label size in the IPv6 header was revised by 372 the IPng working group of the IETF (see Appendix B for further 373 information), we decided to redefine the obsolete FILTER_SPEC (Class 374 10) and SENDER_TEMPLATE (Class 11) objects with C-Type 3 of the 375 original specification. 377 The revised filter spec object is shown here: 379 FILTER_SPEC object: Class = 10, C-Type = 3 380 +-------------+-------------+-------------+-------------+ 381 | | 382 + + 383 | | 384 + IPv6 SrcAddress (16 bytes) + 385 | | 386 + + 387 | | 388 +--------------------+------+-------------+-------------+ 389 | /////// | Flow Label (20 bits) | 390 +--------------------+------+-------------+-------------+ 392 The revised SENDER_TEMPLATE object has the same format. 394 When using RSVP with flow label support, the revised FILTER_SPEC and 395 SENDER_TEMPLATE objects MUST be used in PATH and RESV messages. The 396 SESSION object may be either the IPv6/UDP SESSION object (C-Type 2), 397 as defined in [RFC2205], or the IPv6/GPI SESSION object (C-Type 4), 398 as defined in [RFC2207]. 400 The former uses the destination UDP port as part of the session 401 identifier whereas the latter uses a virtual destination port to 402 demultiplex sessions beyond the IP destination address. The virtual 403 destination port was introduced to support protocols that do not 404 contain transport level ports. 406 5.3 Processing Rules 408 Although the RESV and PATH message formats do not change, the 409 processing of these messages will require modification. 410 Specifically, the (virtual) destination port and the protocol ID of 411 the session object must be used in an appropriate manner for RSVP 412 with flow label support. 414 According to the Version 1 RSVP specification, the destination port 415 and the protocol ID of the session object is used for packet 416 classification, especially to choose the reserved resources of a 417 flow's packet for sessions with the same destination IP address. 418 Since the flow label in RSVP for IPv6 is used as a more efficient 419 packet classifier, neither the destination port nor the protocol ID 420 is used for that purpose anymore. Traffic will be mapped 421 (classified) to reservations entirely based on the flow identifier, 422 namely the tuple (source IP address, flow label). However, the 423 destination ports (DstPort and vDstPort) are still required for 424 session management reasons in order to establish multiple 425 reservations for different sessions with the same destination. 427 Avoiding reliance on the destination port information is absolutely 428 necessary in order to resolve the implicit layer violation problem of 429 standard RSVP packet classification. Furthermore, the protocol ID 430 should not be used for classification since accessing the protocol ID 431 in IPv6 might be very costly due to the variable number of extension 432 headers that need to be skipped first. 434 As a result of this processing modification, all flows to the same IP 435 destination address would share the same reservation when the 436 wildcard filter (WF) reservation style is used. Note, WF style 437 reservation messages do not include explicit sender filterspecs. 438 However, in section 5.4.2 we present a solution which allows multiple 439 WF reservations for the same destination node without need of 440 destination ports and protocol IDs for packet classification. 442 In order to ensure error-free operation of RSVP with flow label 443 support, RSVP implementations in end-user hosts and within the 444 network MUST verify the proper use of the flow label field. 445 Therefore, if the SENDER_TEMPLATE or FILTER_SPEC object (C-Type 3) 446 for flow labels is used in PATH or RESV messages, a unique and 447 (pseudo-) random flow label greater than zero MUST be used. Upon 448 receiving a zero flow label, an error message need to be generated. 449 We suggest use of the Error Code = 09 in the ERROR_SPEC object to 450 indicate that the flow label is unspecified. 452 5.4 Reservation Styles 454 The extended processing rules, as described above, have some 455 ramifications depending upon the reservation style, namely the Fixed- 456 Filter (FF), Shared Explicit (SE), or Wildcard-Filter (WF). 458 5.4.1 Explicit Sender Selection 460 The FF and SE styles have an explicit sender selection. Therefore, 461 the FILTER_SPEC object contains the (SrcAddress, FlowLabel) pair. 462 This allows the receiver to uniquely identify senders based on both 463 elements of the pair. When merging explicit sender descriptors, the 464 senders may only be considered identical when both elements are 465 equal. 467 Upon receiving a RESV message with FF or SE style, RSVP 468 implementations pass the flow identifier of the FILTER_SPEC object 469 along with the flow spec of the FLOW_SPEC object to the local packet 470 classifier. Figure 1 illustrates how the RSVP messages are processed 471 in order to install the included packet filters in the classifier. 473 PATH: s(DstAddr, PId, vPort) PATH: s(DstAddr, PId, vPort) 474 st(SndAddr, FlowLabel) -------- st(SndAddr, FlowLabel) 475 <---------------------------- | | <----------------------------- 476 | RSVPD | 477 ----------------------------> | | -----------------------------> 478 RESV: s(DstAddr, PId, vPort) -------- RESV: s(DstAddr, PId, vPort) 479 filt(SndAddr, FlowLabel) | filt(SndAddr, FlowLabel) 480 flow(...) | flow(...) 481 filt(SndAddr, | flow(...) 482 FlowLabel) | 483 \ / s: SESSION 484 ------------- st: SENDER_TEMPLATE 485 | CLASSIFIER | flow: FLOW_SPEC 486 ------------- filt: FILTER_SPEC 488 Figure 1: Installation of Filters for FF and SE Style Reservations 490 5.4.2 Wildcard Sender Selection 492 In a WF style reservation, the RESV message does NOT contain a 493 FILTER_SPEC since it would be superfluous to specify senders 494 explicitly in a "shared" reservation with "wildcard" sender 495 selection. As a result, classifiers may match all packets containing 496 the session's destination IP address to the same WF reservation. 497 Note, according to the processing rules defined above, we do not make 498 use of the destination port and protocol ID to map traffic to 499 reservations. Therefore, when using WF style reservations, all flows 500 to the same IP destination address using the same IP protocol ID will 501 share the same reservation. 503 A solution for this limitation can be achieved by transparently (from 504 an end user's point of view) simulating the WF reservation style by 505 means of SE reservations. 507 Upon a received RESV message with WF style, intervening routers could 508 identify the corresponding PATH message based on the session object. 509 The router can then extract the sender IP address and the flow label 510 from the SENDER_TEMPLATE object of the PATH message and pass it as a 511 filterspec together with the flow spec to the local packet classifier 512 (see Figure 2). 514 Consequently, packet classification for flows belonging to a WF style 515 reservation is achieved based on individual filterspecs, as in the 516 case of FF or SE style reservations. The drawback of this approach 517 is that the RSVP process must reliably update the filterspecs in the 518 classifier when path state changes. 520 PATH: s(DstAddr, PId, vPort) PATH: s(DstAddr, PId, vPort) 521 st(SndAddr, FlowLabel) -------- st(SndAddr, FlowLabel) 522 <---------------------------- | | <----------------------------- 523 | RSVPD | 524 ----------------------------> | | -----------------------------> 525 RESV: s(DstAddr, PId, vPort) -------- RESV: s(DstAddr, PId, vPort) 526 flow(...) | flow(...) 527 | 528 filt(SndAddr, | flow(...) 529 FlowLabel) | 530 \ / 531 ------------- 532 | CLASSIFIER | 533 ------------- 535 Figure 2: Installation of Filter for WF Style Reservations 537 This solution, suggested by Bob Braden [Braden94] and Markus Jork, 538 makes use of the (virtual) destination port and protocol ID to manage 539 multiple sessions with the same destination IP address. By 540 explicitly defining each sender, the IPv6 flow label can be used to 541 map (classify) packets to their respective QoS reservations. 543 The main disadvantage of this solution is that the scalability 544 feature of WF style reservations disappears when using explicit 545 filters for each sender. 547 However, the advantages of this approach are: it preserves the 548 semantics of the WF reservation style from an end user's viewpoint 549 and exploits the (virtual) destination port and protocol ID 550 exclusively for session management reasons. Packet classification is 551 done entirely based on source address and flow label. Thus, the 552 problem of inefficient classification due to layer violation is 553 resolved. 555 An alternative approach to resolve the limitation of WF style, which 556 is not seen as beneficial as the solution described here, is 557 presented in Appendix A.2. 559 5.5 Packet Classification 561 Besides the changes necessary to the protocol processing rules, the 562 packet classifier also needs to be adapted to make the most of the 563 flow label. These changes are the most promising of all, since use 564 of the flow label allows a significant reduction in the processing 565 cost per packet seen by routers. 567 In order to enable the packet classifier to access state information 568 of active flows with minimal processing cost, it is important that 569 local hash tables or databases of flows are indexed by means of the 570 flow label. This modification is essential as the classification of 571 data packets is primarily based on the flow label when it is non- 572 zero. 574 During the transition period, routers will need mechanisms to provide 575 fast access to flow state information based on the IP address and 576 port, as well as new mechanisms based on the flow label. 578 6 Benefits of Using the Flow Label 580 In this section, we explore the benefits of adopting the flow label 581 for IPv6 based RSVP use. 583 The most important advantage arising from flow label utilization is 584 that it allows RSVP to be implemented without recourse to 585 "clandestine" techniques. Due to the flow semantics of IPv6, the 586 implicit "layer violation problem" is resolvable. As shown in 587 section 5, routers no longer depend on transport or application level 588 protocols to correctly classify packets. 590 The next two subsections discuss advantages directly related to the 591 avoidance of layer violation. In section 6.3 and 6.4, we present 592 additional benefits of the flow label approach. 594 6.1 Efficient Packet Classification 596 In order to show that packet classification based on the flow label 597 improves efficiency, we need some form of measurement to compute the 598 processing cost of packet classification in routers in order to 599 compare the different approaches. 601 For the purpose of illustration, we use a simplified model of the 602 packet classifier which processes packets purely in software. By 603 looking at the operations necessary to classify packets for both 604 approaches, namely IPv4/IPv6 RSVP without flow label support and IPv6 605 RSVP with flow label support, we try to show the complexity decrease 606 and efficiency improvement of the flow label utilization. 608 In general, packet classification in routers is done by identifying a 609 packet's session and matching the packet against the filters of the 610 corresponding session. 612 Without support for flow labels, packet classification requires the 613 following steps: First, the classifier needs to check whether the 614 packet destination IP address belongs to a session. This address 615 lookup could be done by means of hashing. In order to achieve better 616 hashing results, a hash key based on the IP address might have to be 617 computed first. Second, in the case of a hash hit, the DstPort needs 618 to be compared with the session description. This port comparison, 619 which is an inherent layer violation, and therefore costly 620 (especially for IPv6), must be performed frequently if multiple 621 sessions are active for a particular destination node. Third, if the 622 port is identical, a check for the correct protocol ID is required. 623 This test is performed last since it is likely that the second test 624 fails first due to the unsuited distribution of port numbers 625 (individual applications use usually the same ports). After the 626 identification of the packet's session, the filterspec must be 627 matched. This is done by searching a list of filters associated with 628 the session. In order to find the correct filter, the fourth step, 629 comparing the source IP address, needs to be performed. And finally, 630 if it matches any of the filter's addresses, the source port must be 631 checked. This is also very likely, if we assume that sessions have 632 multiple flows, for example one for audio and one for video. 634 A serious problem in this approach is the inability to identify 635 whether a packet belongs to a flow that requires special handling or 636 not without performing the expensive classification first. 638 Packet classification based on the IPv6 flow label has important 639 advantages over the former approach. As already mentioned in section 640 4, the flow label can be used to immediately identify whether packets 641 belong to a flow or not. 643 Another advantage arising from the flow label property that they are 644 (pseudo-)randomly assigned is: the flow label or any set of bits 645 within the flow label field can be used as a hash key. No additional 646 cost due to hash key generation is incurred. Furthermore, since the 647 flow label is (pseudo-)randomly selected, it is most likely a 648 "better" hash key than a hash key generated from the source address 649 in the sense that it causes less hash collisions and, as a result, 650 less processing costs for classification. 652 In the case of packet classification with flow label support, the 653 processing required in the router is much simpler: First, the flow 654 label is used as a hash key to look up whether flow state exists for 655 a packet. In the case of a hash hit, it is most likely that the 656 correct flow state entry is directly identified due to the random 657 nature of flow labels. However, to make sure it is not a collided 658 hash entry, the source IP addresses must be matched against the 659 filterspec address as a final step. 661 Even without exploring the exact costs for each of the operations 662 described above, and the actual probability that packets belong to a 663 session or flow, it seems clear that the processing efficiency of 664 packet classification with flow label is a significant improvement 665 over that currently exploited by RSVP. A more detailed analysis with 666 numerical results is given in [Schmid98]. 668 The main reason for the efficiency gain of the latter approach lies 669 in the fact that flow state information can be indexed with the flow 670 label as an identifier instead of using a key based on destination IP 671 addresses and the avoidance of layer violation. 673 The performance comparison outlined here is based on a software 674 processing model. One could easily argue that this does not hold if 675 these operations are processed in hardware or with hardware support 676 as in real routers. However, even then, the analysis still gives 677 insights about the complexity of the required operations and, 678 therefore, provides information about possible hardware 679 implementation costs. 681 6.2 Enabling Network Layer Security Mechanisms 683 Network layer security in the currently deployed Internet is usually 684 achieved using IP security, or IPSEC, protocols [RFC1825] such as 685 packet level authentication [RFC1826] and integrity and 686 confidentiality [RFC1827]. The IPSEC extensions provide service by 687 adding new headers, namely the Authentication Header (AH) and/or 688 Encapsulating Security Payload (ESP), between the IP header and the 689 transport protocol header. 691 When using the IPSEC protocol within RSVP, first, access to the 692 transport protocol ports requires modifications in the case of IPv4 693 and second, transport ports might be hidden from intervening routers 694 when encryption is used. Therefore, security mechanisms within 695 Version 1 of RSVP are only applicable on a per host, rather than a 696 per flow basis. 698 Hence, RSVP Extensions for IPSEC were defined in [RFC2207] so that 699 data flows containing IPSEC protocols can be controlled at a 700 granularity similar to that already specified for UDP and TCP. The 701 RSVP extension proposes the usage of the IPSEC Security Parameter 702 Index, or SPI, in place of the UDP/TCP-like ports. The announcement 703 of flow specific SPIs for the intermediate RSVP routers nodes 704 requires a new FILTER_SPEC and SESSION object which includes the 705 IPSEC SPI. 707 However, in IPv6 RSVP, the flow label can be used directly as an 708 identifier to distinguish multiple flows from a source address to the 709 same destination. The advantage of using the flow label to 710 demultiplex flows is that the flow label field of the IPv6 header is 711 not encrypted by any network level security mechanism and, therefore, 712 it can easily be used for packet classification in conjunction with 713 IPSEC by the routers along a reserved path. 715 As a result, when using RSVP with flow label support, the IPSEC 716 extensions for RSVP become obsolete. 718 6.3 Efficient Packet Forwarding 720 The IP packet forwarding process of routers is computationally 721 expensive when options (in IPv4) or extension headers (IPv6) need to 722 be processed. Each packet carrying such additional routing 723 information increases the processing load and the end-to-end delay. 725 According to the IPv6 specification, all datagrams with the same 726 (non-zero) flow label and source address must have the same 727 destination address, Hop-by-Hop options header (excluding the Next 728 Header field) and Routing header contents. As a result, by 729 exploiting the flow label, the IP packet forwarding can be performed 730 more efficiently. Simply by looking up the flow label in a flow 731 information table, the router can decide how to route and forward the 732 datagram without examining the rest of the header. Therefore, the 733 expensive options or extension header processing must not be done on 734 a per packet basis. 736 In summary, use of the flow label within RSVP also allows 737 simplification and improvement of the standard IP packet forwarding 738 task. 740 6.4 Additional Prospects of the Flow Label 742 Utilizing the flow label within resource reservation protocols such 743 as RSVP for real-time data streaming has, besides the advantages 744 mentioned above, additional potential. 746 Reserving resources by means of the flow label has provision to 747 reduce problems caused by frequent route changes, e.g. route 748 "fluttering". 750 Currently deployed IP routing protocols cause route changes either 751 when "new routes becoming available" for a given destination or as a 752 result of "existing routes being lost". For the latter case, IP 753 routing provides a sophisticated error recovery mechanism for RSVP. 754 For example, if a link is going down, IP routing protocols try to 755 find a new path to a given destination node. RSVP PATH and RESV 756 messages automatically adopt this path and try to establish resource 757 reservations for the relevant flows. A local repair mechanism was 758 defined in order to establish reservations on new links immediately 759 after a router change. In the cases when required resources are not 760 available on the new link, the flows lose their QoS. This behavior 761 is perfectly acceptable if a route is lost. However, route changes 762 due to "new routes becoming available" are not desirable since they 763 might cause unnecessary QoS loss. 765 The flow semantics of IPv6 could be exploited in future RSVP 766 implementations to support route "pinning" mechanisms for reserved 767 flows. For example, data flows of QoS sensitive real-time streams 768 could be "pinned" to a route which would prevent the flow from being 769 moved to another route unless this is essential. 771 Furthermore, the IPv6 flow label facilitates simplified QoS based 772 flow routing techniques when interworking with connection-orientated 773 networks such as ISDN and ATM [Race98]. 775 Finally, ongoing research in the area of label switching proposes 776 approaches that make use of IPv6 flow labels to identify the 777 appropriate reservation state of RSVP for a packet based on its label 778 value. Thus, the packet is switched with respect to its reservation 779 state. The Internet Draft [Davie98] suggests a way to distribute 780 label bindings using RSVP messages by introducing a new RSVP object 781 RSVP_LABEL to carry a label in an RSVP message. 783 7 Security Considerations 785 Since the adoption of the flow label to RSVP as described in this 786 note does not introduce new data fields, besides the flow label, and 787 does not require additional messages, we can apply the security 788 considerations stated in [RFC2205] to this note. 790 In addition, the flow label represents another data element about the 791 IP flow that might be available to an adversary. The label values 792 might be useful to an adversary engaging in traffic analysis by 793 monitoring not only the data packets of the IP flow but also the RSVP 794 control messages associated with the flow. One possible approach to 795 prevent such attacks would be the deployment and the use of 796 appropriate link-layer encryption mechanisms. However, protection 797 against traffic analysis attacks is outside the scope of this memo. 799 8 References 801 [Braden94] Braden, B., "Presentation: RSVP for IPv6", RSVP working 802 group meeting, San Jose, December 1994, online at: 803 ftp://ftp.isi.edu/rsvp/ietf.meetings/sanjose.ietf/ 804 braden.issues.ps. 806 [Davie98] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., 807 Srinivasan, V., and Blake, S., "Use of Label Switching 808 With RSVP", IETF Internet-Draft (work in progress), 809 draft-ietf-mpls-rsvp-00.txt, March 1998. 811 [Deerin98] Deering, S. and Hinden, R., "Internet Protocol, Version 6 812 (IPv6) Specification", IETF Internet-Draft (work in pro- 813 gress), draft-ietf-ipngwg-ipv6-spec-v2-02.txt, August 1998 815 [Hinden97] Hinden, B., "Minutes of the IETF IPng Working Group 816 Meeting in Munich", August 1997, online at: 817 http://www.cs-ipv6.lancs.ac.uk/ipv6/documents/standards/ 818 general-comms/ietf/ipngwg/ipngwg-minutes-97aug.txt. 820 [Race98] Race, N., Dunmore, M., Shepherd, D., "Supporting QoS over 821 Heterogeneous Networks using RSVP and IPv6", Proceedings 822 of IDC'98 'Technology Serving the Information Society', 823 Lisbon, September 1998. 825 [RFC791] Postel, J., "Internet Protocol", RFC 791, DARPA, 826 September 1981. 828 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 829 Suite". RFC 1349, July 1992. 831 [RFC1809] Partridge, C.,"Using the Flow Label Field in IPv6" 832 RFC 1809, June 1995. 834 [RFC1825] Atkinson, R., "Security Architecture for the Internet 835 Protocol", RFC 1825, NRL, August 1995. 837 [RFC1883] Deering, S. and Hinden, R., "Internet Protocol, Version 6 838 (IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon 839 Networks, December 1995. 841 [RFC2205] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., 842 and S. Jamin, "Resource ReSerVation Protocol (RSVP) 843 -- Version 1 Functional Specification", RFC 2205, 844 September 1997. 846 [RFC2207] Berger, L. and O'Malley, T., "RSVP Extensions for IPSEC 847 Data Flows", RFC 2207, September 1997. 849 [RFC2209] Braden, R., Ed., Zhang, "Resource ReSerVation 850 Protocol (RSVP) -- Version 1 Message Processing 851 Rules", RFC 2209, September 1997. 853 [Schmid98] Schmid, S., Scott, A., Hutchison, D., and Froitzheim, K., 854 "QoS based Real Time Audio Streaming in IPv6 Networks", 855 VV98, Proceedings of SPIE Vol. 3529, Internet Routing and 856 Quality of Service, Boston, 1998. 858 [Zhang95] Zhang, L., "Presentation: IPv6 Flow Label", RSVP working 859 group meeting, Danvers, April 1995, online at: 860 ftp://ftp.isi.edu/rsvp/ietf.meetings/danvers.ietf/ 861 zhang.flow-labels6up.ps 863 9 Acknowledgments 865 The work presented in this memo was done within CoBrow - a research 866 project funded in parts by the European Community under the 867 Telematics Applications Program and the Swiss Federal Office of 868 Science and Education. Initial research and prototype implementation 869 was carried out in Eurescom project P702 'IPv6 - Opportunities for 870 Service Providers and Public Network Operators'. Special 871 appreciation goes to Bob Braden and Markus Jork 872 for their technical advise. Finally, we like to 873 thank Laurent Mathy and Joe Finney 874 for their editorial and technical comments. 876 10 Authors' Addresses 878 Stefan Schmid Dr. Andrew Scott 879 Distributed Multimedia RG Distributed Multimedia RG 880 Computing Department Computing Department 881 Lancaster University Lancaster University 882 Lancaster LA1 4YR Lancaster LA1 4YR 883 United Kingdom United Kingdom 884 Phone: (+44) 7970 419935 Phone: (+44) 1524 65201 885 EMail: sschmid@comp.lancs.ac.uk EMail: acs@comp.lancs.ac.uk 887 Martin Dunmore Nicholas Race 888 Distributed Multimedia RG Distributed Multimedia RG 889 Computing Department Computing Department 890 Lancaster University Lancaster University 891 Lancaster LA1 4YR Lancaster LA1 4YR 892 United Kingdom United Kingdom 893 Phone: (+44) 1524 593819 Phone: (+44) 1524 593819 894 EMail: dunmore@comp.lancs.ac.uk EMail: race@comp.lancs.ac.uk 896 A Alternative Solutions 898 This Appendix describes alternative approaches for the various 899 solutions presented throughout this memo that could be adopted for 900 flow label processing within RSVP along with our reasons for 901 discarding them. 903 A.1 Ignore (Virtual) Destination Port and Protocol ID in SESSION Object 905 The approach presented in this section proposes an alternative 906 solution for the utilization of the IPv6 flow label within RSVP 907 (compare section 5). 909 The alternative approach suggests that the (v)DstPort and protocol ID 910 of the session object should be ignored avoiding ambiguity by 911 mandating it to be zero. By doing this, we implicitly limit the 912 number of sessions per destination to one. 914 For RSVP without flow label support, the destination port and 915 protocol ID of the session object were required only to enable 916 routers to differentiate multiple flows originating from the same 917 port and destined to the same IP address. Without these additional 918 identification criterias, all flows would have shared the same 919 reservations. However, when exploiting the flow label within RSVP, 920 all flows can be unambiguously distinguished based on the sender 921 address and flow label. Thus, the (virtual) destination port and 922 protocol ID of the session object is not necessarily required 923 anymore. 925 This argument, however, holds only in the case of explicit sender 926 selection which is used for FF and SE style reservations. When using 927 WF, due to the lack of filterspecs, all reservations would be 928 established with respect to the destination's IP address. Without 929 using the destination port and protocol ID as further demultiplexing 930 information, all the flows would automatically share the same 931 reservations. 933 Nevertheless, since our main concern is to resolve the implicit layer 934 violation problem of RSVP which is caused by the dependency of higher 935 layer demultiplexing information such as the transport level ports, 936 ignoring the (virtual) destination port in the session object seems 937 to be the logical conclusion. However, in section 5.4.2 we have 938 shown that the additional session demultiplexing information provided 939 by (virtual) destination ports can be used to establish multiple WF 940 reservations which do not depend on this higher level information to 941 achieve proper packet classification. 943 Since we could not gain anything from the "reduced" session 944 semantics, except simplicity, but lost the capability of resolving 945 the problem of multiple WF style reservations for a single 946 destination, we came to the conclusion that this approach should be 947 rejected. 949 A.2 Use of "Receiver Selected" or "Predefined" Flow Labels 951 An alternative approach to resolve the limitation of WF style 952 reservations by means of the IPv6 flow label (compare section 5.4.2) 953 is to utilize "receiver selected" flow labels. Here, the destination 954 selects the flow label which is then used by the sender to label the 955 data packets and by the classifier to map them to their QoS 956 reservations. 958 One problem arising from the fact that receivers choose the flow 959 label is: the flow label must be propagated to the sender nodes. 960 This could be done either within the RSVP protocol itself by using 961 the RESV message or by means of any session description (e.g. SDP, 962 SAP) or session setup protocol (e.g. SIP, RTSP). In order to 963 transmit the flow label, the former approach would demand either a 964 modification of the session object or a new definition of the SESSION 965 object. 967 In the case of multicast sessions with multiple senders and 968 receivers, the approach described is not suitable since multiple 969 receivers would select different flow labels which would then create 970 different sessions. Therefore, "predefined" flow labels could be 971 required. Session announcement including a flow label could be 972 achieved by adopting the currently deployed mechanisms for multicast 973 session announcement (i.e. SDP, SAP). 975 The advantage of this approach is that packet classifiers require 976 only one filter per session for WF style reservations. In contrast 977 to the solutions proposed in section 5.4.2, this practice preserves 978 the scalability property of WF style reservations. 980 On the other hand, the major drawback of this approach is: it 981 implicitly changes the flow label semantics defined in [RFC1889, 982 RFC1809]. The flow label would not be "sender selected" anymore. 983 This modification causes further problems that would have to be 984 resolved first. For example: how would a sender react on receiving a 985 "receiver selected" or "predefined" flow label which is already in 986 use by another flow? 988 The fact that the flow label semantics (which is a fundamental part 989 of the basic IPv6 specification [RFC1889]) would implicitly be 990 changed when deploying this alternative approach, led the authors to 991 dismiss this alternative. 993 B Revised IPv6 Header 995 In the meeting of the IETF in Munich in August 1997, the IPng working 996 group agreed to redefine the priority and flow label field 997 [Hinden97]. 999 The Priority field is renamed in a "Class" field and its length is 1000 enlarged to eight bits. The fact that a change to the priority 1001 semantics took place (relative priorities were discarded) due to open 1002 loop transmission problems, and the need for more control bits to 1003 improve the congestion avoidance algorithm of RED, led the working 1004 group to the decision to revise the priority field. 1006 As a result of the increased length of the "Class" field, the flow 1007 label field was reduced to 20 bits. The leading four octets of the 1008 revised IPv6 header are presented here: 1010 4 8 20 1011 +-----+----------+---------------------------------------+ 1012 | Ver | Class | Flow Label | 1013 +-----+----------+---------------------------------------+ 1015 See [Deerin98] for further information on the IPv6 protocol.