idnits 2.17.1 draft-conta-ipv6-flow-label-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** 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 143: '... The keywords MUST, MUST NOT, MAY, O...' RFC 2119 keyword, line 144: '... SHALL, SHALL NOT, SHOULD, SHOULD NO...' RFC 2119 keyword, line 511: '... Deterministic behavior is a MUST in a...' RFC 2119 keyword, line 617: '... flows MAY be aggregated by spe...' RFC 2119 keyword, line 638: '... known, a router MUST not change the v...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 719 has weird spacing: '...s" bits are r...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the action to be performed on a particular flow label is not known, a router MUST not change the value of that flow label. -- 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 (July 2001) is 8322 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 section? 'IPv6' on line 890 looks like a reference -- Missing reference section? 'Intserv' on line 893 looks like a reference -- Missing reference section? 'Diffserv' on line 896 looks like a reference -- Missing reference section? 'MPLS-Arch' on line 927 looks like a reference -- Missing reference section? 'Diffserv-Flow-Label' on line 920 looks like a reference -- Missing reference section? 'KEYWORDS' on line 941 looks like a reference -- Missing reference section? 'Diffserv-Model' on line 1091 looks like a reference -- Missing reference section? 'MPLS-LDP' on line 931 looks like a reference -- Missing reference section? 'RSVP' on line 923 looks like a reference -- Missing reference section? 'RSVP-TE' on line 934 looks like a reference -- Missing reference section? 'PHB ID' on line 876 looks like a reference -- Missing reference section? 'DSCP-Def' on line 900 looks like a reference -- Missing reference section? 'Differv-Tun' on line 865 looks like a reference -- Missing reference section? 'IPSec-ESP' on line 938 looks like a reference -- Missing reference section? 'PHD ID' on line 877 looks like a reference -- Missing reference section? 'CONS' on line 944 looks like a reference -- Missing reference section? 'PHB-ID' on line 904 looks like a reference -- Missing reference section? 'Diffserv-Tun' on line 907 looks like a reference -- Missing reference section? 'Diffserv-PIB' on line 910 looks like a reference -- Missing reference section? 'DiffServ-MIB' on line 914 looks like a reference -- Missing reference section? 'Assign' on line 1023 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng Working Groups A. Conta (Transwitch) 2 INTERNET-DRAFT B. Carpenter (IBM) 3 July 2001 5 A proposal for the IPv6 Flow Label 7 Specification 9 draft-conta-ipv6-flow-label-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 At the time when the IPv6 specifications were written, the IPv6 flow 35 label was still experimental, and subject to change, as the 36 requirements for flow support in the Internet were evolving. 38 The last several years of work in IETF on Internet Protocols Quality 39 of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching 40 (MPLS) provide a more solid and ample architectural perspective, and 41 framework for the standardization of the IPv6 flow label. The new 42 charter of the IPv6 Working Group invites contributions to this 43 standardization. 45 This memo provides an analysis of the IPv6 definition of the flow 46 label, the rules governing its use, and their implications. It 47 subsequently makes a proposal for additions/modifications to these 48 rules, which improve the usability of the IPv6 flow label, in 49 particular with Diffserv, and its acceptance as a standard mechanism. 51 Table of Contents 53 1. Introduction....................................................4 54 2. IPv6 Flows......................................................5 55 3. Other Definitions of Flows......................................5 56 3.1 Integrated Services Flows...................................5 57 3.2 Differentiated Services Flows...............................6 58 3.3 MPLS Flows..................................................7 59 4. IPv6 Flow Label.................................................7 60 5. IPv6 Flow and Flow Label Discussion.............................9 61 5.1 Flow Label Processing by Integrated Services Routers........9 62 5.2 Flow Label Processing by Differentiated Services Routers....9 63 5.3 Flow Label based Filtering.................................10 64 5.4 End-to-end/Hop-by-hop use of the IPv6 Flow Label...........10 65 5.5 Mutable/Non-Mutable IPv6 Flow Label........................12 66 5.6 Using Random Numbers in setting the IPv6 Flow Label........12 67 5.7 IPv6 Multi-Field Classifier Efficiency.....................13 68 5.7.1 Classification Rules Memory Requirements.............13 69 5.7.2 Pipe-Lined or Parallel Processing Classification.....14 70 6. Summary of Proposals for the IPv6 Flow Label...................14 71 7. IPv6 Flow Label Definition and Characteristics.................15 72 7.1 IPv6 Flow Label Format.....................................17 73 7.1.1 Diffserv IPv6 Flow Label Format......................17 74 7.1.2 Other Possible IPv6 Flow Label Formats...............18 75 7.2 Conceptual Model for Diffserv use of IPv6 Flow Labels......18 76 8. Security Considerations........................................21 77 9. IANA Considerations............................................21 78 10. Acknowledgments...............................................21 79 11. References....................................................21 80 12. Authors' Addresses............................................23 81 Appendix A........................................................24 82 1. Introduction 84 As stated by [IPv6], at the time when the IPv6 specifications were 85 written, the IPv6 flow label was still experimental, and subject to 86 change, as the requirements for flow support in the Internet were 87 evolving. 89 The last several years of work in IETF on Internet Protocols Quality 90 of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching 91 (MPLS) provide a more solid and ample architectural perspective, and 92 framework for the standardization of the IPv6 flow label. The new 93 charter of the IPv6 Working Group invites contributions to this 94 standardization. 96 Note: The IETF work on Intserv, Diffserv, MPLS is documented in several 97 specifications, among which the architecture documents [Intserv], 98 [Diffserv], and respectively [MPLS-Arch]. Intserv and Diffserv present 99 two alternative solutions to resolving QoS problems in the Internet, 100 while MPLS is a technology based on labeling traffic flows. 102 The IPv6 flow label is a function that, as it was designed, can be 103 used towards a more efficient processing of packets in next hop 104 lookup, quality of service, or packet filtering engines in IPv6 105 forwarding devices. These devices would normally be IPv6 routers or 106 switches. However, the current IPv6 flow label definition and 107 specification can be further clarified or even improved, in 108 particular in regards to Differentiated Services Quality of Service 109 (Diffserv). 111 Diffserv seems to have more potential, and could be used more 112 extensively than originally thought. For instance, for IP QoS in 113 access networks, Diffserv could be used on individual flows of 114 traffic between users and the access networks. The nature of the 115 contractual agreements between the users and the access network 116 providers seem to create an environment in which Diffserv with 117 Multi-Field (M-F) classifiers could be easier to use, more efficient, 118 and more practical as an alternative to Intserv and RSVP. 120 However, the Diffserv M-F classifiers, the 5 or 6 element tuple, 121 containing host-to-host protocol id, and source and destination 122 ports, is a bit of a problem when packets have extension headers 123 (IPv4, or IPv6). In IPv6, that is even more of an efficiency problem 124 (need for sequential inspection), since extension headers have a much 125 wider and frequent use. 127 The IPv6 flow label, and the use of IPv6 flow label classifiers would 128 be a big help in alleviating this problem. An IPv6 flow label 129 classifier is basically a 3 element tuple - source and destination 130 IPv6 addresses, and the IPv6 flow label [Diffserv-Flow-Label]. It is 131 an alternative to the 5 element tuple (addresses, ports, and 132 protocol). It will help the IPv6 flow label to achieve, as it is 133 supposed, a more efficient processing of packets in quality of 134 service engines in IPv6 forwarding devices. 136 This specification provides an analysis of the definition of the IPv6 137 flow label [IPv6], the rules governing its use, and attempts to make 138 clarifications to their implications. It subsequently suggests some 139 additions, or modifications to these rules, which in the view of the 140 authors, improve the usability of the IPv6 flow label, in particular 141 with Diffserv, and its acceptance as a standard mechanism. 143 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 144 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 145 defined in [KEYWORDS]. 147 2. IPv6 Flows 149 A flow is a sequence of packets sent from a particular source, and a 150 particular application running on the source host, using a particular 151 host-to-host protocol for the transmission of data over the Internet, 152 to a particular (unicast or multicast) destination, and particular 153 application running on the destination host, or hosts, with a certain 154 set of traffic, and quality of service requirements. 156 3. Other Definitions of Flows 158 As IPv6 relies on Quality of Service Mechanisms defined by the 159 Integrated Services Architecture or the Differentiated Services 160 Quality of Service Architecture, it is worth considering those 161 architectures flow definitions. The MPLS architecture also defines a 162 technique of labeling flows worth considering. 164 3.1 Integrated Services Flows 166 The Integrated Services architecture [Intserv] defines a flow as an 167 abstraction which is a distinguishable stream of related datagrams 168 that results from a single user activity and requires the same QoS. 169 For example, a flow might consist of one transport connection or one 170 video stream between a given host pair. It is the finest granularity 171 of packet stream distinguishable by the Integrated Services. 173 Furthermore, the Integrated Services architecture [Intserv] defines a 174 classifier: 176 For the purpose of traffic control (and accounting), each incoming 177 packet must be mapped into some class; all packets in the same 178 class get the same treatment from the packet scheduler. This 179 mapping is performed by the classifier. Choice of a class may be 180 based upon the contents of the existing packet header(s) and/or 181 some additional classification number added to each packet. 183 A class might correspond to a broad category of flows, e.g., all 184 video flows or all flows attributable to a particular organization. 185 On the other hand, a class might hold only a single flow. A class 186 is an abstraction that may be local to a particular router; the 187 same packet may be classified differently by different routers 188 along the path. For example, backbone routers may choose to map 189 many flows into a few aggregated classes, while routers nearer the 190 periphery, where there is much less aggregation, may use a separate 191 class for each flow. 193 3.2 Differentiated Services Flows 195 The Differentiated Services architecture [Diffserv] defines a flow or 196 microflow as a single instance of an application-to-application flow 197 of packets, which is identified by the source address, source port, 198 destination address, destination port and protocol id (fields in the 199 IP and host-to-host protocol headers). 201 Furthermore, this architecture defines a classifier as: 203 a mechanism that selects packets in a traffic stream based on the 204 content of some portions of the packet header. Two types of 205 classifiers are defined. The BA (Behavior Aggregate) Classifier 206 classifies packets based on the DS codepoint only. The MF (Multi- 207 Field) classifier [Diffserv-Model] selects packets based on the 208 value of a combination of one or more header fields, such as source 209 address, destination address, DS field, protocol ID, source port 210 and destination port numbers, and other information such as 211 incoming interface. 213 Classifiers are used to "steer" packets matching some specified 214 rule to an element of a traffic conditioner for further processing. 215 Classifiers must be configured by some management procedure in 216 accordance with the appropriate TCA. 218 Note: For the purpose of this document, only a portion of the 219 definition of the classifier from the architecture [Diffserv] is 220 mentioned. 222 3.3 MPLS Flows 224 As it travels from its source to its final destination, an IP packet 225 is being forwarded from one router to the next, each router making an 226 independent forwarding decision (next hop) based on the packet's IP 227 header, and routing information processed and stored. Choosing the 228 next hop can be thought of as the composition of two functions. The 229 first function partitions the entire set of possible packets into a 230 set of "Forwarding Equivalence Classes (FECs)" [MPLS-Arch]. The 231 second maps each FEC to a next hop. Insofar as the forwarding 232 decision is concerned, different packets, which get mapped into the 233 same FEC, are indistinguishable. All packets, which belong to a 234 particular FEC, and which travel from a particular node, will follow 235 the same path (or if certain kinds of multi-path routing are in use, 236 they will all follow one of a set of paths associated with the FEC). 237 In MPLS, the assignment of a particular packet to a particular FEC 238 results in a label being associated to that FEC. When a packet is 239 forwarded to its next hop, the label is sent along with it; that is, 240 the packets are "labeled" before they are forwarded. Once a packet is 241 labeled, at subsequent hops, the forwarding is done based on the MPLS 242 label rather than the information in the IP header. The label is used 243 as an index into a table which specifies the next hop, and a new 244 label. The old label is replaced with the new label, and the packet 245 is forwarded to its next hop. 247 4. IPv6 Flow Label 249 The IPv6 Flow Label is defined [IPv6] as a 20 bit field in the IPv6 250 header which may be used by a source to label sequences of packets 251 for which it requests special handling by the IPv6 routers, such as 252 non-default quality of service or "real-time" service. According to 253 [IPv6], the nature of that special handling might be conveyed to the 254 routers by a control protocol, such as a resource reservation 255 protocol, or by information within the flow's packets themselves, 256 e.g., in a hop-by-hop option. 258 The characteristics of IPv6 flows and flow labels, or the rules that 259 govern the flow label functions are further defined in [IPv6]. For 260 the purpose of this document the text from one paragraph in [IPv6] 261 was rearranged as an item list, as follows: 263 (a) A flow is uniquely identified by the combination of a source 264 address and a non-zero flow label. 266 (b) Packets that do not belong to a flow carry a flow label of zero. 268 (c) A flow label is assigned to a flow by the flow's source node. 270 (d) New flow labels must be chosen (pseudo-)randomly and uniformly 271 from the range 1 to FFFFF hex. The purpose of the random 272 allocation is to make any set of bits within the Flow Label 273 field suitable for use as a hash key by routers, for looking up 274 the state associated with the flow. 276 (e) All packets belonging to the same flow must be sent with the 277 same source address, destination address, and flow label. 279 (f) If packets of a flow include a Hop-by-Hop Options header, then 280 they all must be originated with the same Hop-by-Hop Options 281 header contents (excluding the Next Header field of the Hop-by- 282 Hop Options header). 284 (g) If packets of a flow include a Routing header, then they all 285 must be originated with the same contents in all extension 286 headers up to and including the Routing header (excluding the 287 Next Header field in the Routing header). 289 (h) The routers or destinations are permitted, but not required, to 290 verify that these conditions are satisfied. If a violation is 291 detected, it should be reported to the source by an ICMP 292 Parameter Problem message, Code 0, pointing to the high-order 293 octet of the Flow Label field (i.e., offset 1 within the IPv6 294 packet). 296 (i) The maximum lifetime of any flow-handling state established 297 along a flow's path must be specified as part of the description 298 of the state-establishment mechanism, e.g., the resource 299 reservation protocol or the flow-setup hop-by-hop option. 301 (j) A source must not reuse a flow label for a new flow within the 302 maximum lifetime of any flow-handling state that might have been 303 established for the prior use of that flow label. When a node 304 stops and restarts (e.g., as a result of a "crash"), it must be 305 careful not to use a flow label that it might have used for an 306 earlier flow whose lifetime may not have expired yet. 308 5. IPv6 Flow and Flow Label Discussion 310 This section is going to discuss several aspects of the flow label, 311 which are the target of clarifications or improvement. 313 5.1 Flow Label processing by Integrated Services Routers 315 The Integrated Services traffic classification based on flow label in 316 conjunction with the use of the Resource Reservation Protocols (RSVP) 317 for propagating the flow label value seem to be in synchronism. This 318 topic does not require further discussion. 320 The capability to specify a filter based on source, and destination 321 addresses, and flow label presents the advantage of having all the 322 filtering elements in one header, as opposed to multiple headers. 324 5.2 Flow Label processing by Differentiated Services Routers 326 At the time of the writing of this document, the Differentiated 327 Services architecture definition of classifiers [Diffserv] does not 328 seem to include, nor to exclude explicitly the classification of IPv6 329 packets based on flow labels. The definition in [Diffserv-Model] is 330 general enough to invite the use of the flow label. 332 In order to support the Flow Label, a Differentiated Services IPv6 333 classifier definition should be added. This classifier would be a 334 multi-field classifier, which would include as classification fields 335 at least the flow label, and the source address, as the IPv6 336 specification [IPv6] suggests. To allow and use a wild card source 337 address is perhaps debatable. The MF classifier could be extended 338 with the destination address, so it would be a 3 element tuple: 339 source and destination addresses, and flow label. Range of addresses, 340 or range of flow labels may be specified. 342 The definition of a MF classifier based on source, and destination 343 addresses, and flow label presents the advantage of having all the 344 classification elements in one packet header, as opposed to scattered 345 in one packet's multiple headers, that is, the IPv6 main header, and 346 transport (or host-to-host) header. 348 According to the Differentiated Services architecture [Diffserv] the 349 classification fields have values according to the Service Level 350 Agreemnts (SALs), and Traffic Conditioning Agreements (TCAs), 351 (Service Level Specifications -- SLSs, and Traffic Conditioning 352 Specifications -- TCSs) which are contractual agreements between 353 network clients and network service providers. The flow label based 354 Diffserv MF classifier would follow the same model, and would rely on 355 the flow label which is a field with a value or range of values on 356 which clients and service providers would have to agree on. That 357 value, or value ranges of the flow labels would be reflected in SLAs, 358 TCAs, SLSs, and TCSs. 360 As the Diffserv classifier fields are known a priori, before traffic 361 is being generated by a source of packets, the same should apply to 362 the flow label classifier and the flow label value. This is 363 contradicted by a random generation of the flow label value. In order 364 to resolve this contradiction, rule marked (d) in Section 4, 365 extracted from [IPv6], Appendix A, which states that the flow label 366 should be pseudo-random, must be relaxed or removed (a subsequent 367 section is a summary of proposals). 369 5.3 Flow Label based Filtering 371 A similar problem as the Multi-Field classifier contradiction 372 described in the section above occurs with any type of filtering that 373 a forwarding engine may have to perform, in which the filtering rules 374 are configured by a network manager, or are loaded in the forwarding 375 engine by methods other than a resource reservation protocol, or hop 376 by hop signaling. Note that the filtering may have just internal 377 purposes to a forwarding engine, or to a router (which is assumed may 378 have several forwarding engines), or to a segment of the network, or 379 to a network. In all of the cases enumerated above, the expectation, 380 or assumption is that the IPv6 header carries in its fields a set of 381 predictable, or well determined values. This is not the case, if the 382 flow label has a randomly chosen value. 384 This problem of not being able to configure or load filtering rules, 385 which are based or are including the flow label, can be resolved 386 simply by relaxing or removing the rule marked (d) in Section 4, 387 extracted from [IPv6], Appendix A, which is that the flow label must 388 be a random number. 390 5.4 End-to-end/Hop-by-hop use of the IPv6 Flow Label 392 The definition in [IPv6] gives a definite hop-by-hop characteristic 393 to the flow label. The flow label is supposed to help the routing 394 system in processing packets whether during packet forwarding, or 395 whether during QoS processing. However, controversial discussion took 396 place around the end-to-end use and character of the flow label. 398 For instance it was stated that the label should be used as a 399 mechanism for identifying a flow by the destination end-node. Such 400 statements seem to be warranted by the use of the IPv6 pair of source 401 and destination addresses as component fields in host-to-host 402 connection (virtual circuit oriented communication) or communication 403 (connectionless oriented) identifiers, and thus the flow label would 404 just be an addition or a replacement to such identifiers. However, if 405 the routers' packet processing is more performance critical then 406 end-nodes' processing, as the author of this document believes, it 407 would seem to make more sense to use the flow label for that purpose, 408 that is to use the flow label hop-by-hop significance. 410 Using a flow label end-to-end or hop-by-hop seem to be fine in the 411 context of the current definition of the flow label, as long as the 412 non-mutable character of the flow label is maintained. The issue of 413 mutable or non-mutable is going to be discussed in a separate 414 section. 416 The discussion around the end-to-end, or hop-by-hop use of a flow 417 label becomes irrelevant if a certain negotiation mechanism amongst 418 routers and end-nodes takes place. There are examples of technologies 419 in which such negotiations around flow labels and flows labeling take 420 place. For instance the Label Distribution Protocol of MPLS [MPLS- 421 LDP] is used to exchange labels among neighboring MPLS Routers, 422 including the source and the destination of the labeled packets. 423 Furthermore, the Resource Reservation Protocol (RSVP) [RSVP] has been 424 extended [RSVP-TE] to exchange labels between neighboring label 425 switch (MPLS) routers. But such a mechanism, at the time of writing 426 this specification, does not exist for IPv6 flow labels, or as part 427 of the IPv6 set of specifications. However, such a mechanism could be 428 specified in the future, therefore the specification or the 429 definition of the IPv6 flow label should not restrict the use of the 430 flow label in one way or another relative to its end-to-end or hop- 431 by-hop characteristic. 433 In conclusion, the flow label could have a bivalent character in the 434 type of its usage, or in its significance: 436 (i)end-to-end, and 438 (ii)hop-by-hop. 440 The end-to-end significance should not preclude its hop-by-hop 441 significance, and vice-versa. If a node which sends packets, 442 associates a certain end-to-end significance to the flow label of 443 those packets, that significance can be meaningful also hop-by-hop to 444 each downstream router, all the way to the final destination. 445 Furthermore, the flow label could be changed in the packet headers by 446 the en-route routers, and restored or not to its original value by 447 the last hop router, as long as the end-node is aware of what the 448 value of the flow label should be. Certainly such a behavior would 449 need negotiation and state storing in the en-route routers, in 450 particular the last hop one. 452 5.5 Mutable/Non-mutable IPv6 Flow Label 454 Another topic of controversial discussion is whether the flow label 455 should be mutable or non-mutable, that is it should be read-only for 456 routers or not. 458 Statements that advocate a non-mutable characteristic are certainly 459 based on the advantage of the simplicity implied by such a 460 characteristic. 462 Opposite statements, that the flow label should be mutable, are based 463 on the flexibility that this provides, in particular if the label has 464 a hop-by-hop significance. However, using mutable flow labels would 465 not work without a certain agreement, or negotiation between 466 neighboring nodes (routers), or certain configuration of those 467 routers. This would require the use of a negotiation mechanism 468 between neighboring routers, or a certain setup through router 469 management or configuration, to make sure that the values or the 470 changes made to the flow label are known to all routers on the 471 portion of the path of the packet, in which the flow label changes. 472 Some of these mechanisms, such as MPLS Label Distribution Protocol 473 [MPLS-LDP], or RSVP extensions for Traffic Engineering [RSVP-TE}, 474 were briefly mentioned in the previous section. Such a mechanism 475 could be specified for IPv6 flow labels. 477 As the hop-by-hop significance of the flow label can be enhanced by a 478 mutable characteristic, the specification or definition of the flow 479 label should not preclude this. 481 A mutable flow label though requires the relaxation or elimination of 482 the rules marked (a), (c), (d), and (j) in Section 4. These rules 483 were extracted from [IPv6], Appendix A. 485 5.6 Using Random Numbers in setting the IPv6 Flow Label 487 The rule marked (d) in Section 4, extracted from [IPv6], Appendix A, 488 specifies the requirement of pseudo-randomness in setting the value 489 of a flow label. The reason given is the use of a hashing function, 490 and hashing table for flow lookup by routers. Randomness certainly 491 helps if the flow label is the only criterion used in the flow 492 lookup. 494 The use of a hashing mechanism is one possible choice for the flow 495 lookup in routers, or hosts. 497 Another possible choice is to use the label as an index in an array, 498 which is a direct and faster lookup, or retrieval of the flow state, 499 and so a contiguous set of values, starting from 1, would be more 500 helpful, in particular if the flow label is not the only criterion 501 used. 503 However, the authors of this document believe that the specification 504 of the flow label should not mandate any implementation choices, 505 whether they are random values, with hashing functions, or just 506 contiguous values, with array indexing. 508 Furthermore, a random value in the header is introducing the 509 unpredictability of the field. Although this may be an argument of 510 philosophical nature, predictability is a necessary condition for 511 deterministic behavior. Deterministic behavior is a MUST in a 512 network. Network operators may require that packets of a flow have 513 always the same IPv6 content. Random values in the IPv6 flow label 514 certainly break such a requirement. 516 To resolve these issues would certainly require the relaxation or 517 elimination of rule marked (d), in Section 4, extracted from Appendix 518 A of [IPv6]. 520 5.7 IPv6 Multi-Field Classifiers Efficiency 522 This section will address multi-field classification engines 523 efficiency issues. 525 5.7.1 Classification Rules Memory Requirements 527 When the flow label value is completely independent from host-to-host 528 protocol id and source and destination port information, the 529 classification rules that contain MF flow label classifiers are at 530 least partially independent from the classification rules that 531 contain regular MF classifiers. If somewhat the flow label could 532 capture the port and host-to-host protocol information, then the flow 533 label classifier values could be in their entirety inferred from a 534 regular M-F classifier values. This could help in storing 535 classification rules in encoding, and perhaps aggregating information 536 in ways in which memory consumption could be minimized. However, the 537 issue and the gain could be categorized as minor. 539 5.7.2 Pipe-Lined or Parallel Processing Classification. 541 As it was stated above, an IPv4 QoS multi-field classification 542 engine, performs a lookup of 5 or 6 fields of the IP and Host-to-host 543 protocol headers, in the classification rules table. As most of the 544 time, these headers are back to back (contiguous), the position of 545 the fields is well-known, and therefore the processing can be 546 pipelined or parallelized efficiently. Certainly, the existence of 547 one or more IPv4 security headers, disturbs the contiguity of the 548 headers, but as an encrypted packet would have the host-to-host 549 header encrypted, it is likely that its fields would not be part of a 550 classification rule for that packet's flow. 552 In IPv6, in case of a Multi-Field Classifier, the IPv6 extension 553 headers that are potentially located between the IPv6 header and the 554 host-to-host protocol header, need to be processed sequentially, 555 before having access to the host-to-host protocol id, and the host- 556 to-host source and destination ports. This adds a certain degree of 557 difficulty in designing a pipe-lining or parallel processing 558 mechanism. The use of the flow label as a replacement of the host- 559 by-host fields (source and destination ports and protocol id) in the 560 classification rules certainly alleviates this issue. Furthermore, 561 the use of the flow label, relaxes the issue mentioned previously 562 with security headers. 564 6. Summary of Proposals for the IPv6 Flow Label 566 In summary, the following are the actions being proposed: 568 1. For the Differentiated Services M-F Classification rules to 569 include the IPv6 flow label classifer: 571 (i) Write a document that defines a flow label based classifier. This 572 is going to be a separate document, a Differentiated Services 573 specification. 575 (ii)Make a slight change to the flow label definition, by introducing 576 the Diffserv flow label format. 578 (iii)Rules in Appendix A of [IPv6], do not apply to Diffserv IPv6 579 flow labels. 581 2. For the Diffserv IPv6 flow labels: 583 (i) Redefine characteristics or rules (a), (b), (c), (i), (j) for 584 Diffserv IPv6 Flow Labels. 586 (ii) Remove characteristics (e), (f), (g) for Diffserv IPv6 flow 587 labels. They prevent certain ways of aggregating flows into one flow. 589 The following section, contains the text that specifies the newly 590 suggested IPv6 flow label definition and rules. They would apply to 591 Diffserv flows, and to the use of flow label based non-QoS filtering. 592 They could also apply to Intserv flows, since there is no technical 593 reason that would prevent that. 595 7. IPv6 Flow Label Definition and Characteristics 597 The IPv6 Flow Label is a 20 bit field in the IPv6 header which may be 598 used to label packets of the same packet flow, or aggregation of 599 flows. This labeling can be used by IPv6 Quality of Service engines 600 in routers, for packet classification, policing, and scheduling. It 601 can also be used by IPv6 filtering engines in routers, that use 602 filtering for various purposes. Documenting such filtering purposes 603 is beyond the scope of this document. 605 The flow label values can be communicated to routers through a 606 resource reservation protocol, by a flow label distribution protocol, 607 or by information within the flow's packets themselves, e.g., in a 608 hop-by-hop option. They can also be configured in routers, manually, 609 or by ways of some automated procedures, or simply uploaded through 610 management or policy control procedures. 612 The characteristics of IPv6 flows and flow labels are further defined 613 as: 615 (a) A flow is uniquely identified by the combination of source 616 address, destination address and a non-zero flow label. Diffserv 617 flows MAY be aggregated by specifying a range of addresses 618 and/or a range of flow labels (see further in (e)). 620 (b) A flow label of zero means that the flow label has no 621 significance, the field is unused, and therefore has no effect 622 on, or for the packet processing by forwarding, QOS, or 623 filtering engines. 625 (c) A flow label is assigned to a flow by the flow's source node. It 626 can be changed en-route, with the condition that its original 627 significance be maintained, or restored, when necessary. For 628 instance if the source of the flow intended that the flow label 629 has a certain significance to the destination end-node, than the 630 nodes en-route, that process and eventually change the value of 631 the flow label, should make sure, in conjunction with the 632 destination end-node, that even when the value or significance 633 has changed en-route, the original information and significance 634 is restored when or before the packet arrives to its 635 destination. 637 If the action to be performed on a particular flow label is not 638 known, a router MUST not change the value of that flow label. 640 (d) The flow label must have a value between 1 and FFFFF in hex. It 641 identifies a flow. It is a preset value. No particular method is 642 preferred for choosing the value. However, the value MUST 643 satisfy the following requirements: 645 (i) It can be communicated to all routers on the path of the 646 flow to the final destination, as well as the destination node, 647 by ways of a resource reservation protocol, a flow label 648 distribution protocol, a signaling mechanism, or by any other 649 means. The first method is typical for the Integrated Services 650 model. 652 (ii) It can be configured, uploaded, or transmitted to a router 653 or a group of routers in any other possible way, as long as it 654 can be stored in the classification rules tables of the 655 forwarding engines of routers along the path of the flow to the 656 final destination. If the flow label is used within a 657 Differentiated Services framework, the values of the flow labels 658 are preset or agreed upon, and specified in a Service Level 659 Agreement (SLA), Service Level Specification (SLS), Traffic 660 Conditioning Agreement (TCA), or Traffic Conditioning 661 Specification (TCS) [Diffserv]. This model is typical of 662 Differentiated Services. 664 (e) In general, all packets belonging to the same flow are sent with 665 the same source address, destination address, and flow label. 666 However, flows can be trunked, or aggregated in macro-flows. The 667 flows, members of a macro-flow, may have different source or 668 destination addresses. The trunking, or aggregation of flows is 669 achieved by simply wildcarding some bits or all bits in some of 670 the fields of the multi-field classification rules, which 671 contain source address, destination address, and flow label. In 672 other words range addresses and/or flow labels can be used. 674 (f) The routers or destinations are permitted, but not required, to 675 verify that these conditions are satisfied. If a violation is 676 detected, it should be reported to the source by an ICMP 677 Parameter Problem message, Code 0, pointing to the high-order 678 octet of the Flow Label field (i.e., offset 1 within the IPv6 679 packet). 681 (g) The Diffserv flow labels to not have a time to live rule. 682 However, changes to the value of a flow label of a flow, and/or 683 the correspondent flow label classifier values MUST be 684 synchronized. When the flow label value of a flow is changed, 685 the change must be reflected in the change of the value of the 686 flow label in the multi-Field flow label classifier. 688 7.1 IPv6 Flow Label Format 690 In order to preserve compatibility with the random number method of 691 selecting a flow label value defined in [IPv6], but relax that 692 definition to allow a flow label format that would work with 693 Diffserv, the following new format of the flow label could be used: 695 0 1 696 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |0| Pseudo-Random Value | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 0 1 702 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 |1| Diffserv IPv6 Flow Label | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 7.1.1 Diffserv IPv6 Flow Label Format 709 The Diffserv IPv6 Flow Label is a number that is constructed based on 710 the Differentiated Services "Per Hop Behavior Identification Code" 711 (PHB ID) [PHB ID]: 713 0 1 714 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 |1| Per Hop Behavior Ident. Code | Res | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 The "Res" bits are reserved. 721 Conforming to [PHB ID], the PHB ID is either directly derived from a 722 standard differentiated services code point [DSCP-Def], or it is an 723 "IANA Assigned Value". In either case, it captures the differentiated 724 services treatment intended to be applied to the packet. Unlike the 725 value of the traffic class field, it is not locally mapped and is 726 therefore suitable for use in an end to end header field. Although it 727 captures less specific information than the port numbers and protocol 728 number normally used in an MF classifier, it nevertheless allows for 729 MF classification at a differentiated service domain ingress. 731 7.1.2 Other Possible IPv6 Flow Label Formats 733 There are various other ways in which a Flow Label can be encoded, 734 each way with its advantages and disadvantages. Several ideas of flow 735 label encoding are enumerated in Appendix A. 737 7.2 Conceptual Model for Diffserv use of IPv6 Flow Label 739 Diffserv can be used in IPv6 access networks for IPv6 QoS of 740 individual flows of traffic between users and the access networks. 741 The nature of the contractual agreements between the users and the 742 access network providers create an environment in which Diffserv with 743 Multi-Field (M-F) classifiers could be easier to use, more efficient, 744 and more practical as an alternative to Intserv and RSVP. 746 The IPv6 flow label classifier is basically a 3 element tuple - 747 source and destination IPv6 addresses, and the IPv6 flow label 748 [Diffserv-Flow-Label]. It is an alternative to the 5 element tuple 749 (addresses, ports, and protocol). It helps the IPv6 flow label to 750 achieve, as it is supposed, a more efficient processing of packets 751 in quality of service engines in IPv6 forwarding devices. 753 Whether using algorithmic mapping of port numbers and protocol, IANA 754 values, or just a number randomly chosen, the key for the flow label 755 to work with Diffserv is that the "flow_label value" or range of 756 values MUST be known, and agreed by two sides: the network client and 757 the network provider. The "flow label value" is captured in SLAs, 758 SLSs, TCAs, TCSs. For the mechanism to work several things have to 759 happen: 761 (1.) Packets leaving the client networks carry the correct flow label 762 value. This can be achieved in several ways: 764 a. end-node IPv6 protocol stacks, and/or IPv6 applications can be 765 configured with the flow label "value". The flow label "value" is 766 set first by an application. If the application has not set a flow 767 label "value", then the "value" is set by the protocol stack. The 768 default values would be hard-coded in applications and protocol 769 stacks, or could result from "algorithmic mapping", if such 770 mappings exists. The default value could be zero, in which case the 771 flow label would have no significance. According to this model, 772 when packets are transmitted, end-nodes will force the correct flow 773 label in the IPv6 headers of outgoing packets. 775 if a. is not TRUE, then 777 b. the first hop routers would have to force the correct flow 778 label on packets leaving the network. To accomplish this role, 779 these routers would be configured with MF classifiers. These 780 routers would classify the traffic that is forwarded downstream 781 from, and away from the originating end-nodes. The action 782 subsequent to the classification would be to set the correct flow 783 label in each packet. Classification on such a router's input 784 line card, or interface would result, for the matching packets, in 785 a correct flow label being forced in the IPv6 headers of packets 786 when they are transmitted on the output interface or line card. 788 while it is likely that "b." would not be needed, "a." or "b." would 789 provide the correct flow label in packets leaving the client's 790 network. 792 (2.) Packets coming into the provider network can be policed based on 793 flow label. The provider, based on the SLAs, SLSs, TCAs, TCSs 794 agreed with the client, configures MF classifiers that look like: 796 C = (SA, SAPrefix, DA, DAPrefix, Flow-Label) 798 or 800 C' = (SA, SAPrefix, DA, DAPrefix, Flow-label-Min:FLow-label-Max) 802 Another representation of the classifier for example is: 804 Flow-label-classifier: 805 Type: IPv6-3-tuple 806 IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1 807 IPv6DestPrefixLength: 128 808 IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2 809 IPv6SrcPrefixLength: 128 810 IPv6FlowLabel: 57 812 or 814 Flow-label-classifier: 815 Type: IPv6-3-tuple 816 IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1 817 IPv6DestPrefixLength: 128 818 IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2 819 IPv6SrcPrefixLength: 128 820 IPv6FlowLabelMin: 1 821 IPv6FlowLabelMax: 57 823 and 825 Flow-label-classifier: 826 Type: IPv6-4-tuple 827 IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1 828 IPv6DestPrefixLength: 128 829 IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2 830 IPv6SrcPrefixLength: 128 831 IPv6FlowLabel: 57 832 IPv6DSCP: 28 834 or 836 Flow-label-classifier: 837 Type: IPv6-4-tuple 838 IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1 839 IPv6DestPrefixLength: 128 840 IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2 841 IPv6SrcPrefixLength: 128 842 IPv6FlowLabelMin: 1 843 IPv6FlowLabelMax: 57 844 IPv6DSCP: 28 846 The classifiers are configured in the network provider's edge 847 routers, etc... 849 The classification engines in those routers would match packet 850 header information to classification rules as follows: 852 Incoming packet header (SA, DA, Flow Label) 853 Match 854 Classification rules table entry (C or C') 856 From this step, the Diffserv processing continues the same way as for 857 any other MF Classifier [Diffserv-Model]. 859 8. Security Considerations 861 This document introduces no new security concerns when the pseudo- 862 random flow label format is used. In the case of a diffserv flow 863 label, the security concerns are essentially identical to those 864 concerning the diffserv field (traffic class) itself, as outlined in 865 [DSCP-Def], {Diffserv], and [Differv-Tun]. 867 When IPv6 packets are encrypted using ESP Transport or Tunnel Mode 868 [IPSec-ESP], the port and protocol numbers are hidden, but the flow 869 label is not. Thus MF classification remains possible even for 870 encrypted traffic. 872 9. IANA Considerations 874 The IPv6 flow label format specified in this document, is based on 875 the Differentiated Services Per Hop Behavior Identification Code (PHB 876 ID), specified in [PHB ID]. The PHB ID can be a IANA assigned number. 877 [PHD ID] contains a "IANA Considerations Section", following 878 guidelines stated in [CONS]. No additional IANA considerations have 879 to be made. 881 10.Acknowledgments 883 Some of the ideas in this draft were discussed with Thomas Eklund, 884 and Walter Weiss. Jochen Metzler reviewed the specification and 885 provided good feedback. The continued scrutiny of Steve Deering 886 helped refining the document. 888 11.References 890 [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6 891 Specification", RFC 2460, December 1998. 893 [Intserv] R. Braden, D. Clark, S. Shenker, "Integrated Services in 894 the Internet Architecture: an Overview", RFC 1633, June 1994. 896 [Diffserv] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 897 Weiss, "An Architecture for Differentiated Service", RFC 2475, 898 December 1998. 900 [DSCP-Def] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 901 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 902 Headers", RFC 2474, December 1998. 904 [PHB-ID] D. Black, S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop 905 Behavior Identification Codes", RFC 3140, June 2001. 907 [Diffserv-Tun] D. Black, "Differentiated Services and Tunnels", RFC 908 2983, October 2000. 910 [Diffserv-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, 911 A. Smith, "Differentiated Services Policy Information Base", Work in 912 Progress. 914 [DiffServ-MIB] F. Baker, K. Chan, A. Smith "Management Information 915 Base for the Differentiated Services Architecture", Work in Progress. 917 [Diffserv-Model] Y. Bernet, S. Blake, A. Smith, D. Grossman, "An 918 Informal Management Model for Diffserv Routers", Work in Progress. 920 [Diffserv-Flow-Label] A. Conta, B. Carpenter, "A Definition of a IPv6 921 Flow Label Classifier", Work in Progress. 923 [RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. 924 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 925 Specification", RFC 2205, September 1997. 927 [MPLS-Arch] Rosen, E., Viswanathan, A., and Callon, R., 928 "Multiprotocol Label Switching Architecture", RFC 3031, January 929 2001. 931 [MPLS-LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R. 932 Thomas, "Label Distribution Protocol", RFC 3036, January 2001. 934 [RSVP-TE] D. O. Awduche, L. Berger, D. Gan. Tony Li, Vijay 935 Srinivasan, George Swallow, "RSVP-TE: Extensions to RSVP for LSP 936 Tunnels", Work in progress. 938 [IPSec-ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Protocol 939 (ESP)", RFC 2406, November 1998. 941 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, March 1997. 944 [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 945 Considerations Section in RFCs", RFC 2434, October 1998. 947 [Assign] Postel, J., etc.. "Assigned Numbers", STD 2, RFC 1700, 948 October 1994. 950 12.Authors' Addresses 952 Alex Conta 953 Transwitch Corporation 954 3 Enterprise Drive 955 Shelton, CT 06484 956 USA 957 Email: aconta@txc.com 959 Brian Carpenter 960 IBM 961 c/o iCAIR 962 Suite 150 963 1890 Maple Avenue 964 Evanston, IL 60201 965 USA 966 Email: brian@hursley.ibm.com 967 Appendix A: Other Possible IPv6 Flow Label Formats 969 This section enumerates several ideas, each with its positive and 970 negative aspects. 972 A possible solution to the issues discussed in section 5.7 is to 973 compress or encode the host-to-host header information, and the 974 host-to-host protocol type in the flow label value. This is an 975 algorithmic mapping of the port numbers and protocol into the flow 976 label. There are several ways in which this could be achieved, but 977 only two are suggested in this section. 979 Another format mentioned further down in this section is one in which 980 the length of the IPv6 headers helps locating in one step the host- 981 to-host header for accessing the port information. 983 A.1 Server Port Format - Short Format 985 A possible solution to the issues discussed in section 5.7 is to 986 compress or encode the host-to-host header information, and the 987 host-to-host protocol type in the flow label value. This is an 988 algorithmic mapping of the port numbers and protocol into the flow 989 label. There are several ways in which this could be achieved, but 990 only three are suggested in this section: 992 The Server Port Format is a format which is based on carrying in 993 the flow label the server port number of a client/server 994 application/communication. 996 0 1 997 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Server Port Number | H-to-H protocol| 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 The "Server Port Number" is the port number assigned to the server 1003 side of the client/server application. This provides an 1004 identification of the application, and the type of application, which 1005 is a quite good indication of the type of QoS characteristics needed 1006 for the traffic generated or accepted by that application. Obviously 1007 it does not provide the finer granularity within the use of one 1008 application on the same end-nodes, that the use of both source and 1009 destination ports provide. That is, it cannot differentiate among 1010 multiple instances of the same application running on the same two 1011 communicating end-nodes. But for Differentiated services purposes, it 1012 does not seem to really matter, since it is expected that the several 1013 instances of an application running on the same two end-nodes, would 1014 generate or accept traffic which is of same category, class, or 1015 behavior. 1017 The reduced number of bits (12 bits out of 16) limits the value to 1018 "IANA Well-known ports", that is ports from 1 to 1023, and a subset 1019 of "IANA registered ports" that is, from 1024 to 4095. Registered 1020 ports have values between 1024 and 65535 [Assign]. 1022 The "H-to-H protocol" is the host-to-host protocol identifier 1023 [Assign], that is, TCP, UDP, etc.... 1025 Advantage 1027 The advantage of this flow label format is that the classification 1028 rule is the typical 5 or 6 tuple format of a Diffserv M-F Classifier 1029 [Diffserv-Model], containing the source, and destination addresses, 1030 the source and destination ports (in which one of the two is 1031 wildcard), the host to host protocol, and the DSCP field. So no new 1032 classification rule format is needed, and further, it is possible to 1033 aggregate parts of the IPv4, and IPv6 classification rules. Note that 1034 for classifying traffic in both directions, two classification rules 1035 must be configured. For instance a classification rule for TCP flows 1036 on port 80, between node A, and node B: 1038 Source Address:A 1039 Destination Address:B 1040 Source Port:* 1041 Destination Port:80 1042 Host-to-Host Protocol 6 (TCP) 1044 would be used for all traffic outgoing, from any port, to port 80. 1046 Source Address:A 1047 Destination Address:B 1048 Source Port:80 1049 Destination Port:* 1050 Host-to-Host Protocol 6 (TCP) 1052 would be used for all traffic outgoing from port 80, to any port. 1054 A.2 Server Port Format - Long Format 1056 Observation: Since TCP, and UDP are the two major host-to-host 1057 protocols that carry port numbers in their protocol headers, the 1058 field occupied by the "host-to-host" protocol could be reduced to 1 1059 bit, indicating TCP or UDP, as it follows: 1060 .sp 1061 0 1 1062 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | TCP Server Port Number | Res |0| 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 0 1 1068 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | UDP Server Port Number | Res |1| 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 The "Res" bits are reserved. 1075 The "TCP Server Port Number" or "UDP Server Port Number is the 16 bit 1076 port number assigned to the server side of the client/server 1077 application. 1079 A.3 Header Length Format 1081 Another possible solution to the issues discussed in section 5.7 is 1082 to store the IPv6 headers length, that is the length of the IPv6 main 1083 headers and IPv6 extensions headers preceding the host-to-host, or 1084 transport header. The length of the IPv6 headers in the flow label 1085 value would provide the information which a Diffserv QOS engine 1086 classifier could use to locate and fetch the source and destination 1087 ports, and apply those, along with the source and destination address 1088 and the host-to-host protocol from the flow label, to match the 1089 source and destination address, the source and destination ports and 1090 the protocol identifier elements of a Diffserv M-F classifier 1091 [Diffserv-Model]. 1093 0 1 1094 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 |Length of IPv6 Headers |H-to-H protocol| 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 The "Length of the IPv6 Headers" allows also skipping the IPv6 1100 headers to access directly the host-by-host header for other 1101 purposes. 1103 Additionally, this format is useful for classifying packets that are 1104 not TCP or UDP, and have no source and destination ports. 1106 With this 12 bit encoding the maximum length of the IPv6 headers that 1107 could be represented is 4Kbytes. However, the restriction on headers 1108 length can be significantly reduced. IPv6 headers are 8byte aligned, 1109 therefore the length could be represented as the number of 8byte 1110 chunks occupied by the headers, in which case the maximum length 1111 would be 32Kbytes. 1113 If all of the above formats would be used, then there are two ways to 1114 separate this last type of encoding from the other two mentioned 1115 above: 1117 (i) always use a signaling mechanism to distribute the flow label 1118 values, and so the type of the format would be stored as part of the 1119 flow state. 1121 (ii) use a bit field to discriminate the formats. For instance, a two 1122 bit field could be used to indicate the first, second, or third type 1123 of format. 1125 Note: 1127 The suggestions described in this section are in fact an exploration 1128 of possible solutions. Each suggestion has advantages and 1129 disadvantages. They are kept in this section at least for recording 1130 purposes. 1132 1593