IPng Working Groups A. Conta (Transwitch) INTERNET-DRAFT May 2001 A proposal for the IPv6 Flow Label Specification draft-conta-ipv6-flow-label-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo provides an analysis and describes a proposal for the IPv6 Flow Label, that may be regarded as creating a certain degree of limitations. 1. Introduction This document contains an analysis of the current definition of the IPv6 flow label, and its implications. It further specifies a proposal for the IPv6 Flow Label. At this point, it is rather a place holder, a stake in the ground, for a couple of ideas that have to be further discussed, and developed. Conta Expires in six months [Page 1] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 The IPv6 flow label is a function that, as it was designed, can be used towards a more efficient processing of packets in lookup, or quality of service engines in IPv6 forwarding devices. However the current IPv6 flow label definition and specification can be further clarified or even improved in particular in regards to Differentiated Services Quality of Service. So, this specification attempts to make clarifications, and suggests some additions or modifications to the definition and specification of the IPv6 flow label, which in the view of the author would be an improvement. The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [KEYWORDS]. 2. IPv6 Flows A flow is a sequence of packets sent from a particular source, and a particular application running on the source host, using a particular host-to-host protocol for the transmission of data over the Internet, to a particular (unicast or multicast) destination, and particular application running on the destination host, with a certain set of quality of service requirements. 3. Other Definitions of Flows As IPv6 relies on Quality of Service Mechanisms defined by the Integrated Services Architecture or the Differentiated Services Quality of Service Architecture, it is worth considering those architectures flow definitions: 3.1 Integrated Services Flows The Integrated Services architecture [Intserv-Arch] defines a flow as an abstraction which is a distinguishable stream of related datagrams that results from a single user activity and requires the same QoS. For example, a flow might consist of one transport connection or one video stream between a given host pair. It is the finest granularity of packet stream distinguishable by the Integrated Services. Furthermore, the Integrated Services architecture [Intserv-Arch] defines a classifier: For the purpose of traffic control (and accounting), each incoming packet must be mapped into some class; all packets in the same class get the same treatment from the packet scheduler. This Conta Expires in six months [Page 2] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 mapping is performed by the classifier. Choice of a class may be based upon the contents of the existing packet header(s) and/or some additional classification number added to each packet. A class might correspond to a broad category of flows, e.g., all video flows or all flows attributable to a particular organization. On the other hand, a class might hold only a single flow. A class is an abstraction that may be local to a particular router; the same packet may be classified differently by different routers along the path. For example, backbone routers may choose to map many flows into a few aggregated classes, while routers nearer the periphery, where there is much less aggregation, may use a separate class for each flow. 3.2 Differentiated Services Flows The Differentiated Services architecture [Diffserv-Arch] defines a flow or microflow as a single instance of an application-to- application flow of packets, which is identified by the source address, source port, destination address, destination port and protocol id (fields in the IP and host-to-host protocol headers). Furthermore, this architecture defines a classifier as a mechanism that selects packets in a traffic stream based on the content of some portion of the packet header. Two types of classifiers are defined. The BA (Behavior Aggregate) Classifier classifies packets based on the DS codepoint only. The MF (Multi-Field) classifier selects packets based on the value of a combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and other information such as incoming interface. Classifiers are used to "steer" packets matching some specified rule to an element of a traffic conditioner for further processing. Classifiers must be configured by some management procedure in accordance with the appropriate TCA. Note: For the purpose of this document, only a portion of the definition of the classifier from the architecture [Diffserv] is mentioned. 4. IPv6 Flow Label The IPv6 Flow Label is defined [IPv6] as a 20 bit field in the IPv6 header which may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as Conta Expires in six months [Page 3] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 non-default quality of service or "real-time" service. According to [IPv6], the nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. The characteristics of IPv6 flows and flow labels are further defined in [IPv6]: (a) A flow is uniquely identified by the combination of a source address and a non-zero flow label. (b) Packets that do not belong to a flow carry a flow label of zero. (c) A flow label is assigned to a flow by the flow's source node. (d) New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. (e) All packets belonging to the same flow must be sent with the same source address, destination address, and flow label. (f) If packets of a flow include a Hop-by-Hop Options header, then they all must be originated with the same Hop-by-Hop Options header contents (excluding the Next Header field of the Hop-by- Hop Options header). (g) If packets of a flow include a Routing header, then they all must be originated with the same contents in all extension headers up to and including the Routing header (excluding the Next Header field in the Routing header). (h) The routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP Parameter Problem message, Code 0, pointing to the high-order octet of the Flow Label field (i.e., offset 1 within the IPv6 Conta Expires in six months [Page 4] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 packet). (i) The maximum lifetime of any flow-handling state established along a flow's path must be specified as part of the description of the state-establishment mechanism, e.g., the resource reservation protocol or the flow-setup hop-by-hop option. (j) A source must not reuse a flow label for a new flow within the maximum lifetime of any flow-handling state that might have been established for the prior use of that flow label. When a node stops and restarts (e.g., as a result of a "crash"), it must be careful not to use a flow label that it might have used for an earlier flow whose lifetime may not have expired yet. 5. IPv6 Flow and Flow Label Discussion This section is going to discuss several aspects of the flow label, which are the target of clarifications or improvement. 5.1 End-to-end/hop-by-hop use of the IPv6 Flow Label The definition in [IPv6] gives a definite hop-by-hop characteristic to the flow label. The flow label is supposed to help the routing system in processing packets whether during packet forwarding, or whether during QoS processing. However, controversial discussion took place around the end-to-end use and character of the flow label. For instance it was stated that the label should be used as a mechanism for identifying a flow by the destination end-node. Such statements seem to be warranted by the use of the IPv6 pair of source and destination addresses as component fields in a host-to-host connection (virtual circuit oriented communication) or communication (connectionless oriented) identifiers, and thus the flow label would just be an addition or a replacement to such identifiers. However, if the routers' packet processing is more performance critical then end-nodes' processing, it would seem to make more sense to use the flow label for that purpose, that is to use the flow label hop-by-hop significance. Using a flow label end-to-end or hop-by-hop seem to be fine in the context of the current definition of the flow label, as long as the non-mutable character of the flow label is maintained. The issue of mutable or non-mutable is going to be discussed in a separate section. Conta Expires in six months [Page 5] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 The discussion around the end-to-end, or hop-by-hop use of a flow label becomes irrelevant if a certain negotiation mechanism amongst routers and end-nodes takes place. There are examples of technologies in which such negotiations around flow labels and flows labeling take place. For instance the Label Distribution Protocol of MPLS is used to exchange labels among neighboring Label Distribution Routers, including the source and the destination of the labeled packets. Furthermore, the Resource Reservation Protocol (RSVP) [RSVP],[RSVP- TE] Has been extended to exchange labels between neighboring labels. But such a mechanism, at the time of writing this specification, does not exist for IPv6 flow labels, or as part of the IPv6 set of specifications. However, such a mechanism could be specified in the future, therefore the specification or the definition of the IPv6 flow label should not restrict the use of the flow label in one way or another relative to its end-to-end or hop-by-hop characteristic. In conclusion, the flow label could have a bivalent character in the type of its usage, or in its significance: (i)end-to-end, and (ii)hop-by-hop. The end-to-end significance should not preclude its hop-by-hop significance, and vice-versa. If a node which sends packets, associates a certain end-to-end significance to the flow label of those packets, that significance can be meaningful also hop-by-hop to each downstream router, all the way to the final destination. Furthermore, the flow label could be changed in the packet headers by the en-route routers, and restored or not to its original value by the last hop router, as long as the end-node is aware of what the value of the flow label should be. Certainly such a behavior would need negotiation and state storing in the en-route routers, in particular the last hop one. 5.2 Mutable or non-mutable IPv6 Flow Label Another topic of controversial discussion is whether the flow label should be mutable or non-mutable, that is it should be read-only for routers or not. Statements that advocate a non-mutable characteristic are certainly based on the advantage of the simplicity implied by such a characteristic. Opposite statements, that the flow label should be mutable, are based on the flexibility that this provides, in particular if the label has a hop-by-hop significance. However, using mutable flow labels would not work without a certain agreement, or negotiation between neighboring nodes, or certain configuration of those routers. This would require the use of a negotiation mechanism between neighboring routers, or a certain setup through router management or Conta Expires in six months [Page 6] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 configuration, to make sure that the values or the changes made to the flow label are known to all routers on the portion of the path of the packet, in which the flow label changes. Some of these mechanisms, such as MPLS LDP, or RSVP-TE, were described in the previous section. Such a mechanism could be specified for IPv6 flow labels. As the hop-by-hop significance of the flow label can be enhanced by a mutable characteristic, the specification or definition of the flow label should not preclude this. A mutable flow label though requires the relaxation or elimination of the rule marked (a), (c), (d), and (j) in Section 4. These rules were extracted from [IPv6], Appendix A. 5.3 Randomness in setting Flow Label values The rule marked (d) in Section 4, extracted from [IPv6], Appendix A, specifies the requirement of pseudo-randomness in setting the value of a flow label. The reason given is the use of a hashing function, and table for flow lookup by routers. The use of a hashing is one possible choice for the flow lookup in routers, or hosts. Another possible choice is to use the label as an index in an array, which is a direct and much faster lookup, or retrieval of the flow, and so a contiguous set of values, starting from 1, would be more helpful. However, the author of this document believes that the specification of the flow label should not mandate certain implementation choices. This would certainly require the relaxation or elimination of rule marked (d). 5.4 Flow Label processing by Integrated Services Routers The Integrated Services traffic classification based on flow label in conjunction with the use of the Resource Reservation Protocols (RSVP) for propagating the flow label value seem to be in synchronism. This topic does not require further discussion. 5.5 Flow Label processing by Differentiated Services Routers At the time of the writing of this document, the Differentiated Services architecture definition of classifiers [Diffserv] does not seem to include the classification of IPv6 packets based on flow Conta Expires in six months [Page 7] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 labels. In order to support the Flow Label, a Differentiated Services IPv6 classifier definition should be added. This classifier would be a multi-field classifier, which would include as classification fields at least, the flow label, and the source address. To allow a wild card source address is perhaps debatable. Secondly, the Differentiated Services architecture does not make a direct assumption about how flow label information gets propagated or set in routers. Furthermore, according to the afore mentioned architecture, the classification fields have values according to the SLAs, and TCAs, which are contractual agreements between clients and service providers. Therefore, the fields are known a priori, before traffic is being generated by a source of packets. Furthermore, as these values could be configured, or uploaded into the routers, long before traffic is generated, it seems that the pseudo-random character of the flow label values contradicts the model assumed by the Differentiated Architecture. In order to resolve this contradiction, rule marked (d) in Section 4, extracted from [IPv6], Appendix A, should be relaxed or removed. 5.6 IPv6 classifiers efficiency This section will address classification engines efficiency issues 5.6.1 Classifier pipe-lined or parallel processing. As it was stated above, an IPv4 QoS multi-field classification engine, performs a lookup of 5 or 6 fields of the IP and Host-to-host protocol headers, in the classification rules table. As most of the time, these headers are contiguous, the processing can be pipelined or parallelized efficiently. Certainly, the existence of one or more IPv4 security headers, disturbs the contiguity of the headers, but as an encrypted packet would have the host-to-host header encrypted, it is likely that its fields would not be part of a classification rule for that packet's flow. In IPv6, the potential extension headers between the IPv6 header and the host-to-host protocols, which need to be processed sequentially, adds a certain degree of difficulty in designing a pipe-lining or parallel processing mechanism. The use of the flow label as a replacement of the host-by-host fields in the classification rules certainly alleviates this issue. Furthermore, the use of the flow label, relaxes the issue mentioned previously with security headers. Conta Expires in six months [Page 8] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 5.6.2 Classification Rules Memory Requirements One possible issue is that the classification rules that contain flow label values are different than the classification rules that contain host-to-host headers, and this possibly would require more memory to store the classification rules, in particular if one aggregates IPv4, and IPv6 classification rules. However, this issue seems to be minor. A possible solution to the issue discussed in this section is to compress or encode the host-to-host header information, and the host-to-host protocol type in the flow label value. There are several ways in which this could be achieved, but only two are suggested in this section: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Port Number | H-to-H protocol| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IANA Assigned Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "Server Port Number" is the port number assigned to the server side of the application. This provides an identification of the application. Obviously it does not provide the higher granularity within an application that the use of source and destination port provides. The reduced number of bits (12 bits out of 16) also reduces the specification to "well-known" ports only, and applications. The "H-to-H protocol" is the host-to-host protocol identifier, that is, TCP, UDP, etc.... It has the same significance and would be used the same way as the protocol identifier from a Differentiated Services multi-field classification rule. The "IANA Assigned Value" is a value that is assigned by IANA for a particular application that is using a particular host-to-host protocol, and has certain quality of service requirements. Further to be refined. Conta Expires in six months [Page 9] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 Note that there is no differentiation between the two flow labels, that is there is no field that would indicate one versus the other. It does not need one. 5.7 Summary In summary the following are the actions being proposed: (i) Write a document that defines a flow label based classifier. This is going to be a separate document. (ii) A slight change of the flow label definition. (iii) Removing characteristics (a), (d), (i), (j) (iv) Relaxation of (c ), (e), (f), (g) (v) Redefinition of (b) As it follows: Flow Label Definition The IPv6 Flow Label is a 20 bit field in the IPv6 header which may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. According to [IPv6], the nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. It can also be configured in routers, or simply uploaded through management procedures. The characteristics of IPv6 flows and flow labels are further defined as: (a) A flow label of zero means that the flow label field is unused, and therefore has no significance for the packet processing. (b) A flow label is assigned to a flow by the flow's source node. It can be changed en-route, with the condition that its original significance be maintained, or restored, when necessary. For instance if the source of the flow intended Conta Expires in six months [Page 10] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 that the flow label has a certain significance to the destination end-node, than the nodes en-route, that process and eventually change the value of the flow label, should make sure, in conjunction with the destination end-node, that even that if the value or significance has changed en-route, the original information gets to its destination. (c) The flow label must have a value between 1 and FFFFF in hex. It identifies a flow. It can be chosen (pseudo-)randomly in case of use with the Integrated Services QoS model, in which the flow label is transmitted to all routers on the path of the packet to the final destination. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. It can have a preset value, from 1 to FFFFF, if used with Differentiated Services QoS model. The preset value of the flow label can be configured, uploaded, or transmitted in any other possible way, as long as it is stored in the classification rules of the classification rules tables stored in the forwarding engines of routers along the path of the flow. (d) In general, all packets belonging to the same flow are sent with the same source address, destination address, and flow label. However, flows can be trunked, or aggregated in macro-flows. The flows, members of a macro-flow, may have different source or destination addresses. The trunking, or aggregation of flows is achieved by simply wildcarding some bits or all bits in some of the fields of the multi-field classification rules, which contain source address, destination address, and flow label. (h) The routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP Parameter Problem message, Code 0, pointing to the high-order octet of the Flow Label field (i.e., offset 1 within the IPv6 packet). (i) There is no lifetime associated with a flow label. Conta Expires in six months [Page 11] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 5. Security Considerations [tbd] 6. IANA Considerations [tbd] 7. Acknowledgments [tbd] 8. References [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998. [MPLS-Arch] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", Work in Progress, July 2000. [MPLS-LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R. Thomas, "Label Distribution Protocol", Work in Progress, June 2000. [MPLS-Encaps] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress, June 2000. [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in Progress, June 2000. [MPLS-FR] Conta, A., Doolan, P., Malis A. "MPLS Using LDP and ATM VC Switching", Work in Progress, June 2000. Conta Expires in six months [Page 12] INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9. Authors' Addresses Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 email: aconta@txc.com Conta Expires in six months [Page 13] 767