PCN K. Chan Internet-Draft Nortel Intended status: Informational T. Moncaster Expires: August 10, 2008 BT Research M. Menth University of Wurzburg G. Karagiannis University of Twente P. Eardley B. Briscoe BT Research February 7, 2008 Pre-Congestion Notification Encoding Comparison draft-chan-pcn-encoding-comparison-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Chan, et al. Expires August 10, 2008 [Page 1] Internet-Draft Document February 2008 Abstract A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document explores different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide guidance and recommendation based on different criteria. Chan, et al. Expires August 10, 2008 [Page 2] Internet-Draft Document February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Encoding Requirements . . . . . . . . . . . . . . . . . . . . 5 2.1. Encoding States . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Non PCN Capable Packet Encoding State . . . . . . . . 6 2.1.2. Nonce Encoding State . . . . . . . . . . . . . . . . . 7 2.2. Encoding Selection Criteria . . . . . . . . . . . . . . . 7 3. Encoding Options . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Encoding Using ECN and DSCP Fields . . . . . . . . . . . . 9 3.1.1. Benefits of Using DSCP and ECN Fields . . . . . . . . 10 3.1.2. Drawbacks of Using DSCP and ECN Fields . . . . . . . . 11 3.1.3. Comparing DSCP and ECN Fields Encoding Options . . . . 11 3.1.4. Concerns on Alternate Semantics for the ECN Field . . 11 3.1.5. Encoding Choice Considerations . . . . . . . . . . . . 14 3.2. Encoding Using DSCP Field . . . . . . . . . . . . . . . . 14 3.2.1. Benefits of Using DSCP Field . . . . . . . . . . . . . 15 3.2.2. Drawbacks of Using DSCP Field . . . . . . . . . . . . 15 3.2.3. Comparing DSCP Field Encoding Options . . . . . . . . 15 4. Encoding Recommendations . . . . . . . . . . . . . . . . . . . 16 5. Security Implications . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Encoding Using ECN Field . . . . . . . . . . . . . . 17 Appendix A.1. Benefits of Using ECN Field . . . . . . . . . . . . 18 Appendix A.2. Drawbacks of Using ECN Field . . . . . . . . . . . . 19 Appendix A.3. Concerns on Alternate Semantics for the ECN Field . 19 Appendix A.4. Encoding Choice Considerations . . . . . . . . . . . 22 Appendix B. Out-of-Band Channel as Encoding Transport . . . . . 22 Appendix B.1. Benefits of Using Out-Of-Band Channel . . . . . . . 23 Appendix B.2. Drawbacks of Using Out-Of-Band Channel . . . . . . . 23 Appendix C. Current PCN Detection, Marking and Transport Mechanisms . . . . . . . . . . . . . . . . . . . . . 23 Appendix C.1. Detection, Marking and Transport Mechanisms in CL-PHB . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix C.2. Detection, Marking and Transport Mechanisms in Three State Marking . . . . . . . . . . . . . . . . 23 Appendix C.3. Detection, Marking and Transport Mechanisms in Single Marking . . . . . . . . . . . . . . . . . . . 24 Appendix C.4. Detection, Marking and Transport Mechanisms in Load Control Marking . . . . . . . . . . . . . . . . 24 8. Informative References . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Chan, et al. Expires August 10, 2008 [Page 3] Internet-Draft Document February 2008 1. Introduction This document examines the ways to encode pre-congestion notification (PCN) [1] information in IP packets for transporting the information from the PCN interior nodes to the PCN egress nodes. Using the examination results to assist the selection of PCN encoding in IP packets. This document first discuss the PCN information that is required to be transported. Then investigate the different fields in the IP header for transporting the required PCN information. Followed with the encoding choices, discussions, and recommendations, when specific field(s) of the IP header is/are used to transport the PCN information. The main goal of this document is a survey and comparison of several encoding methods that are required to encode the pre-congestion information and to transport it from the PCN interior nodes to the PCN egress nodes. In order to accomplish this comparison, a number of criteria are developed. For transporting using data packet (IP) header, the encoding methods investigated are: 1. Encoding using the combination of the ECN and DSCP bits of a data packet header 2. Encoding using only the DSCP bits of a data packet header We have also considered: 1. Encoding using only the ECN bits of a data packet header 2. Encoding and transport using a different channel than data packets But these have been considered out of scope for the current PCN Charter and hence moved to the Appendix sections. Keeping them for this version of the document to not loose our understanding of them and for completeness of the survey. The rest of this document is organized as follows: o Section 2 describes the encoding requirements indicated by currently known detection and marking mechanisms that can be used within the PCN-domain. o Section 3 describes the encoding options, organized based on the IP header field(s) used for the encoding. Chan, et al. Expires August 10, 2008 [Page 4] Internet-Draft Document February 2008 o Section 4 provides a summary on the encoding options recommendation. 2. Encoding Requirements The internal PCN encoding requirements are based on the functionality of PCN [1], and possibly how the PCN Marking Algorithms achieve the functionality. There may be external requirements depending on the environment in which PCN operates, for example co-existence with ECN as indicated by RFC 4774 [22]. These are discussed secondary to the internal PCN encoding requirements because we have limited the PCN operational environment in the PCN WG's first phase charter. But we also need to take into consideration of the encoding standard should not need to be modified for PCN to work in both current charter's environment and when current charter's environment is expanded. 2.1. Encoding States Currently, there are a number of proposals for Pre-Congestion Detection Algorithms. The authors of the different PCN Algorithm documents have agreed to use the notion of Encoding States to represent the information each algorithm wants to export, and hence to be carried from the interior nodes to the edge nodes for flow admission control and flow termination decisions. These Encoding States form the fundamental functional requirements for the encoding choices. Please notice the number of "Encoding State" can be different from the number of encoding bit patterns. For example more than two "Encoding States" may be carried by two encoding bit pattern when the multiple "Encoding States" can be modulated/ multiplexed over some time domains. For simplicity purpose, we indicate the main required encoding states for PCN capable packets: o Not PreCongested Marking for PCN traffic (PCN), for indication of No Pre-Congestion Indication for PCN capable traffic o Admission Marking (AM), for indication of Flow Admission Information o Termination Marking (TM), for indication of Flow Termination Information o Affected Marking (AfM), for ECMP Information. Chan, et al. Expires August 10, 2008 [Page 5] Internet-Draft Document February 2008 A total of four main required encoding states for PCN capable packets. There are also encoding states that may be required, depending on the environment assumptions made, these encoding states are described in the following sub sections together with their environmental considerations. 2.1.1. Non PCN Capable Packet Encoding State Non PCN Capable packet encoding, for separation from PCN Capable packet. This encoding allows the PCN nodes to provide the PCN treatments to only the PCN Capable packets. Allowing separation between PCN Capable and Non PCN Capable packets. The Working Group assumes the PCN traffic will be identified by the DSCP codepoint it carries. But the precise meaning of this is not entirely clear. There is a question whether: 1. a DSCP is meant to only represent a scheduling behaviour and (pre-)congestion marking behaviour is an optional addition that needs to be turned on or off within each existing DSCP (as for RFC3168 ECN), or 2. we redefine the meaning of the DSCP field to represent a combination of scheduling and marking behaviour. If the first approach is used, for certain PHBs (e.g. EF [rfc3246]) PCN marking would be the congestion marking behaviour turned on by the setting of another field (e.g. the ECN field). Then there would be a need to further distinguish PCN from Not-PCN packets, both using the same DSCP. Requiring a Non PCN Capable Encoding State represented by a bit pattern using bits outside of the DSCP field. In the second approach, for each scheduling behaviour needing to be combined with PCN marking, a new paired DSCP would need to be defined. Then both DSCPs would map to the same scheduling behaviour but one will and one will not receive PCN treatment. For this approach, the DSCP provides the indication of PCN Capable packets. Hence the decision of taking approach one or approach two will indicate if Non PCN Capable Packet Encoding State will be necessary. When the Non PCN Capable Packet Encoding State is needed, we use the encoding of Not-PCN Capable (Not-PCN) to represent this state. The use of the other required PCN Encoding States will indicate this is a PCN Capable Packet. Chan, et al. Expires August 10, 2008 [Page 6] Internet-Draft Document February 2008 Superficially, the proposed new DSCP for capacity-admitted traffic [6] seems like it could turn on PCN marking with EF scheduling (approach 2). In this document an early version of PCN is given as an example of schemes that might need to use the new voice-admit codepoint. But the proposed new DSCP for capacity-admitted traffic [6] is really intended to distinguish EF traffic that is admission controlled per flow at the edge of a Diffserv domain from EF traffic merely policed in bulk. The new codepoint is not really intended to switch on a new marking behaviour like PCN. 2.1.2. Nonce Encoding State The ECN nonce RFC 3540 [19] for end-to-end ECN is used to protect the sender from cheating by the receiver and/or by other down stream nodes. PCN may or may not need a mechanism like the ECN nonce. However single bit nonce schemes such as the ECN nonce require in- order, reliable data delivery to function correctly. As PCN operates at the IP layer, in-order delivery cannot be guaranteed. If PCN needs a nonce functionality, it may need to think beyond the current ECN nonce mechanism. And this is beyond the scope of this document. Currently, the PCN work we are doing assumes the trust relationship between all the functional entities are already established. If this assumption is not true, the trust relationships will need to be addressed, but may or may not involve the needing of additional encoding states or the use of the ECN nonce mechanism. 2.2. Encoding Selection Criteria Two possible locations within the IP header have been identified as suitable for encoding PCN. These are the 2 bit ECN field whose default meaning is defined in RFC 3168 [16] and the 6 bit DSCP field defined in RFC 2474 [11] and RFC 2475 [12]. It is already accepted that PCN traffic will be distinguished according to which DSCP codepoint it carries. The implications of this decision were discussed in section 2.1.1 above. The current assumption is that PCN will need to be specified as the marking behaviour through definition of a new PCN DSCP. There are a number of other potential issues that might affect the exact choice of encoding to be used. The key ones are: 1. The support of the required encoding states to satisfy the functional requirement of PCN. 2. Compliance with RFC 4774 [22] if the ECN field is to be re-used for PCN encoding. Chan, et al. Expires August 10, 2008 [Page 7] Internet-Draft Document February 2008 3. Compliance with the requirements for specifying DSCPs and DSCP per-hop-behaviour groups [11]. Each of these are examined in further details in encoding option sections describing their usage. RFC 4774 [22] have also required one to give consideration to what harm might be caused by the leaking of PCN traffic into a non-PCN domain. The following looks at each ECN codepoint and shows what harm, if any, would be caused were that codepoint to leak from the PCN domain: o '00': The leak should be safe in all circumstances. RFC 3168 compliant routers will believe such packets to be not-ECN capable and as such will drop them if the router is congested. This codepoint may be suitable for different use by PCN. o '01' and '10': RFC 3168 compliant routers will believe these packets are from an ECN capable flow. If the routers are congested they will mark these packets '11' (CE) instead of dropping them. If the endpoints are not ECN capable then this is not good for congestion control. The use of '01' and '10' by PCN can be a potential issue. To be completely safe, it would be best to avoid giving any PCN semantics to these codepoints. o '11': If the packet was already part of an ECN capable flow then receivers will believe this was an indication of congestion on the path. They will thus inform their source of this and the source will perform a congestion response. This codepoint may be suitable for different use by PCN, the degree of suitability may depend on the exact PCN encoding and the metering and marking algorithm using the encoding. More detailed consideration of these points are provided in the sections describing the encoding options. Additional criterion of handling ECN packets traversing the PCN domain brings up the notion of tunneling in the PCN domain. As indicated earlier, the working group is using a different DSCP to indicate a PHB for PCN packets. We can take the view of using such DSCP, hence the PCN PHB, as handling the PCN packets in its own tunnel. And the other non-PCN packets are in one or more other tunnels. Taking this view allows us to totally separate the PCN and non-PCN (including ECN) traffic using DiffServ. Allowing an easy solution for ECN packets traversing the PCN domain. With violation of such traffic separation be considered leakage of other traffic into the PCN domain and leakage of PCN traffic out of the PCN domain. Chan, et al. Expires August 10, 2008 [Page 8] Internet-Draft Document February 2008 With the above discussion, in additon to the criteria indicated so far, we should give higher preference to encoding options that: o Minimize problems if there are packet leakage by the PCN domain. o Is safest for wider deployment of PCN, when the current chartered environment restriction is relaxed. 3. Encoding Options There are couple of methods to carry the encoding states. The method used affects the encoding options. Hence when we describe the different encoding options in this section, we group them based on how the encoding states are carried. The encoding transport methods considered are: o using the combination of the ECN and DSCP bits of a data packet header o using only the ECN bits of a data packet header o using only the DSCP bits of a data packet header We discuss the encoding options for each of the encoding transport methods separately in their own subsections. For shorter reading, we have moved the encoding choices the working group have agreed to not consider (Using only ECN field, Out-of-Band Channel) sections to the Appendix. 3.1. Encoding Using ECN and DSCP Fields The use of both DSCP and ECN fields is following the second approach indicated in section 2.1.1. This approach allows a clean traffic treatment separation of PCN Capable traffic and Non PCN Capable traffic. This natural use of the DSCP field, to provide treatment differentiation of packets using different DSCP encoding, is one way of providing the "PCN Capable Transport Marking" encoding state. The using of this approach allows us to focus on encoding the four required PCN Encoding States indicated in section 2.1 using the two ECN bits. Chan, et al. Expires August 10, 2008 [Page 9] Internet-Draft Document February 2008 ----------------------------------------------------------------------- | ECN Bits || 00 | 01 | 10 | 11 || DSCP | |==============++==========+==========+==========+==========++==========| | RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA | |==============++==========+==========+==========+==========++==========| | Option 1 || AM | PCN | PCN | TM || PCN | |--------------++----------+----------+----------+----------++----------| | Option 2 || AfM | PCN | PCN | AM/TM || PCN | |--------------++----------+----------+----------+----------++----------| | Option 3 || PCN | NA | NA | AM/TM || PCN | |--------------++----------+----------+----------+----------++----------| | Option 4 || PCN | NA | NA | AM || PCN 1 | | || | | | TM || PCN 2 | |--------------++----------+----------+----------+----------++----------| | Option 5 || AM | TM | PCN | NA || PCN | ----------------------------------------------------------------------- Notes: NA means Not Applicable. PCN, PCN 1, PCN 2 under the DSCP column denotes specific DSCPs used for PCN capable packets. AM/TM means the two encoding states are sharing the same encoding bit pattern. Figure 1: Encoding of PCN Information Using DSCP and ECN Fields In Figure 1, we listed the fundamental options when both DSCP and ECN fields are used. There are couple of variations of the theme provided by these options. For example, the "01" and "10" encoding can be interpreted as PCN(A) and PCN(T) instead of just PCN. Using the PCN(A) and PCN(T) variation provides the additional information of the ratio of packets AM marked to packets Not AM marked, and the ratio of packets TM marked to packets Not TM marked. Having these ratios being independent from one another. Another variation on the theme is the use of an extra DSCP value to represent the TM encoding state for Option 2. Doing so will eliminate the need to modulate both AM and TM using the single "11" encoding. Notice the Affected Mark encoding state is not directly carried by the ECN bits in Option 1. A variation of Option 1 is to represent the Affected Mark encoding state using '01'. But this may result in interference by RFC 3168 ECN routers when there is mis-configuration, please see section 3.1.4 on discussion of RFC 4774 Concern 2 for more details. 3.1.1. Benefits of Using DSCP and ECN Fields A major feature of using both DSCP and ECN fields is the ability to use the inherent nature of DiffServ for traffic class separation to allow PCN treatment be applied to PCN traffic, without concerns of Chan, et al. Expires August 10, 2008 [Page 10] Internet-Draft Document February 2008 applying PCN treatment to none PCN traffic and vise versa. This feature frees this approach for PCN encoding from some of the concerns raised by RFC 4774 [22]. This feature will also keep none PCN Capable traffic out of the PCN treatment mechanisms, allowing the PCN treatment mechanisms focus on their respective PCN tasks. This approach also leaves the ECN field available totally for PCN encoding states purposes. Removing the need to carry the Not-PCN Encoding in the ECN field. 3.1.2. Drawbacks of Using DSCP and ECN Fields The use of both DSCP and ECN fields will require the setting aside of one (or possibly two) DSCP for use by PCN. This may add complexity to the PCN encoding standardization effort. 3.1.3. Comparing DSCP and ECN Fields Encoding Options Here we discuss the differences between the different encoding options when both DSCP and ECN fields are used. There are many encoding options, we have provided the ones we think are favorable in Figure 1. When DSCP is used to differentiate between PCN capable and Not-PCN capable traffic, the encoding of "Not-PCN" in the ECN field is not required. This is the motivation for Option 1 in Figure 1, where the encoding "00" for "Not-ECT" is being used for "AM" (Admission Marking) encoding state. The encodings "01" and "10" for "ECT(1)" and "ECT(0)" supports the required encoding states for "Not Pre- Congested Marking" (PCN), and reserving them for any "Nonce Marking" if necessary. With the possible additional encoding of "PCN(A)" and "PCN(T)" in place of "ECT(1)" and "ECT(0)" for indicating percentage of Admission Marked traffic and percentage of Termination Marked traffic when the algorithm benefits from such additional information. Option 2 in Figure 1 uses the "00" encoding for "AfM". With '01' and '10' encoding the same as for Option 1, requiring the use of "11" encoding for both "AM" (Admission Mark) and "TM" (Termination Mark) states or requiring the allocation of a DSCP for encoding the "TM" state. 3.1.4. Concerns on Alternate Semantics for the ECN Field Section 2 of RFC 4774 [22] raised couple of concerns for usage of alternate semantics for the ECN field. We try to address each of the concerns in this section. Chan, et al. Expires August 10, 2008 [Page 11] Internet-Draft Document February 2008 1. Section 3.1 of RFC 4774 [22] discusses Concern 1: "How routers know which ECN semantics to use with which packets." This use of DSCP and ECN for encoding PCN states address this by following the recommendation of RFC 4774 [22] on using a diffserv codepoint to identify the packets using the alternate ECN semantics. This diffserv codepoint may possibly be a new diffserv codepoint to minimize the possible confusion between using the old per hop behavior of the codepoint and the using of the alternate ECN semantics per hop behavior of the codepoint. 2. Section 4 of RFC 4774 [22] discusses Concern 2: "How does the possible presence of old routers affect the performance of the alternate ECN connections." With the notion of old routers meaning routers that performs RFC 3168 ECN processing instead of PCN processing. The easy answer is the environment using the alternate ECN semantics is envisioned to be within a single administrative domain. With the ability to ensure that all routers along the path understand and agree to the use of the alternate ECN semantics for the traffic identified by the use of a diffserv codepoint. This uses option 2 indicated in section 4.2 of RFC 4774 [22]. But incase there is mis-configuration, the choice of encoding may make a difference: * With encoding Option 1, the old routers will interprete: + '00' encoding as Not-ECT, and will drop AM marked packets. The PCN edge nodes should not admit traffic that it does not receive, hence the PCN admission functionality should be OK. + '01' encoding as ECT(1), which indicates ECN capable and can be remarked to '11' to indicate congestion experienced. The RFC 3168 ECN CE encoding have the same functionality as the PCN TM encoding, to reduce the offered traffic load. Hence the PCN termination functionality should be OK. + '10' encoding as ECT(0). The discussion for '01' above applies equally to this encoding. + '11' encoding as CE. The old router should use this encoding to reduce the offered traffic load and should not remark this to any other ECN encoding, the same functionality the PCN TM encoding requires, hence should be OK for PCN. The above discussion for Option 1 applies equally for PCN traffic leaked out of the PCN domain and interpreted by RFC 3168 ECN nodes. Chan, et al. Expires August 10, 2008 [Page 12] Internet-Draft Document February 2008 * With encoding Option 2, the old routers will interprete: + '00' encoding as Not-ECT, and will drop AfM marked packets. This may possibly affect the efficiency of the Affected Marking functionality. + '01' encoding as ECT(1), which indicates ECN capable and can be remarked to '11' to indicate congestion experienced. The RFC 3168 ECN CE encoding have the same functionality as the PCN TM encoding, to reduce the offered traffic load. Depending on the PCN algorithm on how AM and TM share the same '11' encoding, this may or may not affect the functionality of PCN. + '10' encoding as ECT(0). The discussion for '01' above applies equally to this encoding. + '11' encoding as CE. The old router should use this encoding to reduce the offered traffic load and should not remark this to any other ECN encoding. Depending on the PCN algorithm on how AM and TM share the same '11' encoding, this may or may not affect the functionality of PCN. The above discussion for Option 2 applies equally for PCN traffic leaked out of the PCN domain and interpreted by RFC 3168 ECN nodes. 3. Concern 3: "How does the possible presence of old routers affect the coexistence of the alternate ECN traffic with competing traffic on the path." Within the PCN domain, the PCN (alternate ECN) traffic is separated from the other traffic using diffserv. If by mis-configuration, an old routers that does not understand PCN handles PCN traffic, the PCN traffic will get the per hop behavior as the other traffic, hence not receiving the benefits of PCN at the old router, but will not affect the coexistence of the PCN and the other traffic. If the old router uses RFC 3168 ECN congestion treatment, then the discussion for Concern 2 above applies. 4. Concern 4: "How well does the alternate ECN traffic perform." The performance of the different proposed PCN (alternate ECN) metering and marking algorithms are currently under study with their simulation and study results described by their respective documents. The environment using the alternate ECN semantics is envisioned to be within a single administrative domain. With the ability to ensure Chan, et al. Expires August 10, 2008 [Page 13] Internet-Draft Document February 2008 that all routers along the path understand and agree to the use of the alternate ECN semantics for the traffic identified by the use of a diffserv codepoint. This uses option 2 indicated in section 4.2 of RFC 4774 [22]. 3.1.5. Encoding Choice Considerations o If three encoding states need to be separately represented, Option 1 is recommended. o If two encoding states need to be separately represented, for example the marking algorithm allows the AM and TM encoding states be represented using the same bit pattern, Options 2 and 3 are recommended. o If RFC 4774 [22] concerns need to be addressed by PCN encoding, then Option 1 is recommended, please see section 3.1.4 for the detail discussion. Options 2 and 3 may be able to address the RFC 4774 [22] concerns, but a heavier burden is placed on the metering and marking algorithms to differentiate between TM and AM meaning of the '11' encoding when a RFC 3168 ECN router sets the '11' encoding. o If the metering and marking algorithm requires the use of Affected Marking encoding state, Option 2 is recommended. Alternatively one of the bit patterns of '01' or '10' may be used for the AfM purpose. But using '01' or '10' bit patterns for AfM may increase the interference between RFC 3168 ECN and PCN encodings, please see section 3.1.4 for the detail discussion. o If Option 1 is used and the functionality of Affected Marking encoding state is required, the metering and marking algorithms will need to provide this functionality without the use of the Affected Marking encoding state. 3.2. Encoding Using DSCP Field In this type of encoding and transport method the congestion and precongestion information is encoded into the 6 DSCP bits that are transported in the IP header of the data packets. Four possible alternatives can be distinguished, as can be seen in Figure 3, with details provided by draft-westberg-pcn-load-control-02.txt [4]. Option 7 needs 2 additional DSCP values, Options 8 and 9 need three additional DSCP values and Option 10 needs four additional DSCP values. Note that all additional and experimental DSCP values are representing and are associated with the same PHB. The 1st, 2nd, 3rd, and 4th DSCP values are representing DSCP values that are assigned by IANA as DSCP experimental values, see RFC 2211 [9]. Chan, et al. Expires August 10, 2008 [Page 14] Internet-Draft Document February 2008 ----------------------------------------------------------------------- | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 |Add DSCP 4 | |===========++==========+===========+===========+===========+===========| | Option 6 || Not-PCN | PCN | AM/TM | NA | NA | |-----------++----------+-----------+-----------+-----------+-----------| | Option 7 || Not-PCN | PCN | AM/TM | AfM | NA | |-----------++----------+-----------+-----------+-----------+-----------| | Option 8 || Not-PCN | PCN | AM | TM | NA | |-----------++----------+-----------+-----------+-----------+-----------| | Option 9 || Not-PCN | PCN | AM | TM | AfM | ----------------------------------------------------------------------- Notes: Not-PCN means the packet is not PCN capable. Figure 2: Encoding of PCN Information Using DSCP Field 3.2.1. Benefits of Using DSCP Field The main benefit of using the DSCP field is that it is not affecting the end-to-end ECN semantics and therefore the issues and concerns raised in RFC 4774 [22] are not applicable for this encoding scheme. Another benefit is related to the fact that all 4 DSCP encoding options depicted in Figure 3 can support the PCN capable not congested (PCN) indication, the admission control (AM) and flow termination (TM) encoding states. In addition Option 8 and 10 can support the ECMP solution. 3.2.2. Drawbacks of Using DSCP Field This type of encoding needs to use per PHB, in addition to the original DSCP and depending on the encoding option used, one, two, three, or four DSCP values, respectively. These additional DSCP values can be taken from the DSCP values that are not defined by standards action, see RFC 2211 [9]. Note that all the additional DSCP values are representing and are associated with one PHB. The value of this DSCP/PHB can either follow a standards action or use a value that is applied for experimental or local use. It is important to note that the number of the DSCP values used for local or experimental use is restricted and therefore the number of different PHBs supported in the PCN domain will also be restricted. 3.2.3. Comparing DSCP Field Encoding Options Option 6 can support the basic encoding states, i.e,.not PCN, not congested PCN (PCN), and the AM/TM encoding states. Option 7 can support the basic encoding states supported by Option 6, but in addition it can support the AfM state. Option 8 can support the following basic encoding states: not PCN, not congested PCN(PCN), AM Chan, et al. Expires August 10, 2008 [Page 15] Internet-Draft Document February 2008 and TM states. Option 9 can support the states supported by Option 8, but in addition it can support the AfM state. 4. Encoding Recommendations 5. Security Implications Packets from normal precedence and higher precedence sessions [24] aren't distinguishable by PCN Interior Nodes. This prevents an attacker specifically targeting, in the data plane, higher precedence packets (perhaps for DoS or for eavesdropping). However, PCN End Nodes can access this information to help decide whether to admit or terminate a flow. The separation of network information provided by the Interior Nodes and the precedence information at the PCN End Nodes allows simpler, easier and better focused security enforcement. PCN End Nodes police packets to ensure a flow sticks within its agreed limit. This is similar to the existing IntServ behaviour. Between them the PCN End Nodes must fully encircle the PCN-Region, otherwise packets could enter the PCN-Region without being subject to admission control, which would potentially destroy the QoS of existing flows. It is assumed that all the Interior Nodes and PCN End Nodes run PCN and trust each other (ie the PCN-enabled Internet Region is a controlled environment). For instance a non-PCN router wouldn't be able to alert that it's suffering pre-congestion, which potentially would lead to too many calls being admitted (or too few being terminated). Worse, a rogue router could perform attacks such as marking all packets so that no flows were admitted. So security requirements are focussed at specific parts of the PCN- Region: The PCN End Nodes become the trust points. The degree of trust required depends on the kinds of decisions it has to make and the kinds of information it needs to make them. For example when the PCN End Node needs to know the contents of the sessions for making the decisions, when the contents are highly classified, the security requirements for the PCN End Nodes involved will also need to be high. PCN-marking by the Interior Nodes along the packet forwarding path needs to be trusted, because the PCN End Nodes rely on this information. Chan, et al. Expires August 10, 2008 [Page 16] Internet-Draft Document February 2008 6. IANA Considerations To be completed. 7. Acknowledgements To be completed. Appendix A. Encoding Using ECN Field This section takes the approach 1 option indicated in section 2.1.1. Which the DSCP field only indicates the packet forwarding behavior, for which both PCN Capable and Non PCN Capable traffic use/share the same DSCP. This approach requires the use of the Not PCN Capable Encoding State to be encoding using the ECN bits. Hence this section describes the encoding options that uses only the ECN field (without the DSCP field) available in the IP header of the data packets to encode the PCN states. The use of the same DSCP for both PCN Capable and Non PCN Capable also opens the question of having PCN and RFC 3168 ECN traffic using the same DSCP. Which increases the importance of satisfying the concerns indicated in RFC 4774. ----------------------------------------------------------------------- | ECN Bits || 00 | 01 | 10 | 11 || DSCP | |==============++==========+==========+==========+==========++==========| | RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA | |==============++==========+==========+==========+==========++==========| | Option 10 || Not-PCN | AM | PCN | TM || NA | |--------------++----------+----------+----------+----------++----------| | Option 11 || Not-PCN | PCN | PCN | AM/TM || NA | |--------------++----------+----------+----------+----------++----------| | Option 12 || Not-PCN | AfM | PCN | AM/TM || NA | ----------------------------------------------------------------------- Figure 3: Encoding of PCN Information Using ECN Field In Figure 2, we listed the fundamental options when only the ECN field is used. Like in Figure 1, there are variations of the theme provided by these options. For example, when both "01" and "10" encoding are used for NPM in Option 4, they can be interpreted as PCN(A) and PCN(T) instead of just PCN. Using the PCN(A) and PCN(T) variation provides the additional information of the ratio of packets AM marked to packets Not AM marked, and the ratio of packets TM Chan, et al. Expires August 10, 2008 [Page 17] Internet-Draft Document February 2008 marked to packets Not TM marked. Having these ratios being independent from one another. For Option 10, the use of '01' for AM and '10' for PCN can be swapped and provide the same functionality. For Option 12, the use of '01' for AfM and '10' for PCN can also be swapped without change of functionality. Appendix A.1. Benefits of Using ECN Field The using of only the ECN field for encoding PCN encoding states allow more efficient use of the DSCP field, not requiring the allocation of PCN specific DSCP values. This approach also opens the question of possibly having both PCN and ECN traffic using the same DSCP. When the same treatment can be provided to both ECN and PCN traffic to achieve each of ECN and PCN purpose, then not having DiffServ as separation between ECN and PCN traffic may be a benefit. Under such circumstances, having the same encoding between ECN and PCN may be desireable. But this can only be true if the requirement set forth in RFC 4774 [22] for alternate ECN semantics can be satisfied. If the same treatment can be applied to both ECN and PCN traffic, then: o The first issue of RFC 4774 [22]: "How routers know which ECN semantics to use with which packets." may be solved because there are no difference in the treatments of ECN and PCN packets, hence they can use the same semanics. o The second and third issues of RFC 4774 [22]: "How does the possible presence of old routers affect the performance of the alternate ECN connections." and "How does the possible presence of old routers affect the coexistence of the alternate ECN traffic with competing traffic on the path." are also solved because there are no difference in the treatment of ECN and PCN packets. o The forth issue of RFC 4774 [22]: "How well does the alternate ECN traffic perform." are dependent on the algorithm used, and should be provided by the respective algorithm document, and not in the scope of this document. Chan, et al. Expires August 10, 2008 [Page 18] Internet-Draft Document February 2008 Appendix A.2. Drawbacks of Using ECN Field Notice this group of encoding options does not use DiffServ code points for PCN encoding. With this group of encoding options, the required states of "PCN Capable Transport"/"None PCN Capable Transport" must be encoded using the ECN field. Leaving less encoding real estate to carry the remaining required PCN encoding states. Another drawback is without the protection/separation capability provided by DiffServ, it is typically harder to satisfy the requirement set forth in RFC 4774 [22] for alternate ECN semantics. Appendix A.3. Concerns on Alternate Semantics for the ECN Field Section 2 of RFC 4774 [22] raised couple of concerns for usage of alternate semantics for the ECN field. We try to address each of the concerns in this section. 1. Section 3.1 of RFC 4774 [22] discusses Concern 1: "How routers know which ECN semantics to use with which packets." When this group of PCN encodings are used without the use of DSCP, routers can not distinguished PCN encoded packets from RFC 3168 ECN encoded packets. Hence there needs to be some kind of differentiation between PCN and RFC 3168 ECN packets, may be using PCN for real-time traffic types (with specific DSCP) and ECN for elastic traffic (with specific DSCP). And only distinguishing PCN Capable and Non-PCN Capable packets in real- time traffic. Only distinguishing ECT and Not-ECT packets in elastic traffic. But not having PCN and ECN traffic together. 2. Section 4 of RFC 4774 [22] discusses Concern 2: "How does the possible presence of old routers affect the performance of the alternate ECN connections." With the notion of old routers meaning routers that performs RFC 3168 ECN processing instead of PCN processing, or drop packets instead of encoding the congestion information. The easy answer is the environment using the alternate ECN semantics is envisioned to be within a single administrative domain. With the ability to ensure that all routers along the path understand and agree to the use of the alternate ECN semantics for the traffic identified to be PCN Capable. This uses option 2 indicated in section 4.2 of RFC 4774 [22]. But incase there is mis-configuration, the choice of encoding may make a difference: * With encoding Option 10, the old routers will interprete: + '00' encoding as Not-ECT, and will drop Not-PCN marked packets when congestion is detected. With '00' the Chan, et al. Expires August 10, 2008 [Page 19] Internet-Draft Document February 2008 encoding for Not-PCN, requiring the same functionality as Not-ECT, the presence of old routers will not affect the performance of PCN functionality. + '01' encoding as ECT(1), which indicates ECN capable and can be remarked to '11' to indicate congestion experienced. For Option 3, the old router can possibly remark AM to TM. This puts a burden on the metering and marking algorithms to treat TM encoded packets to indicate stop admission. This may or may not be acceptable, depending on the algorithm. + '10' encoding as ECT(0), which indicates ECN capable and can be remarked to '11' to indicate congestion experienced. The RFC 3168 ECN CE encoding have the same functionality as the PCN TM encoding, to reduce the offered traffic load. Hence the PCN termination functionality should be OK. + '11' encoding as CE. The old router should use this encoding to reduce the offered traffic load and should not remark this to any other ECN encoding, the same functionality the PCN TM encoding requires, hence should be OK for PCN. The above discussion for Option 10 applies equally for PCN traffic leaked out of the PCN domain and interpreted by RFC 3168 ECN nodes. * With encoding Option 11, the old routers will interprete: + '00' encoding as Not-ECT, and will drop Not-PCN marked packets when congestion is detected. With '00' the encoding for Not-PCN, requiring the same functionality as Not-ECT, the presence of old routers will not affect the performance of PCN functionality. + '01' encoding as ECT(1), which indicates ECN capable and can be remarked to '11' to indicate congestion experienced. The RFC 3168 ECN CE encoding have the same functionality as the PCN TM encoding, to reduce the offered traffic load. Depending on the PCN algorithm on how AM and TM share the same '11' encoding, this may or may not affect the functionality of PCN. + '10' encoding as ECT(0). The discussion for '01' above applies equally to this encoding. Chan, et al. Expires August 10, 2008 [Page 20] Internet-Draft Document February 2008 + '11' encoding as CE. The old router should use this encoding to reduce the offered traffic load and should not remark this to any other ECN encoding. Depending on the PCN algorithm on how AM and TM share the same '11' encoding, this may or may not affect the functionality of PCN. The above discussion for Option 11 applies equally for PCN traffic leaked out of the PCN domain and interpreted by RFC 3168 ECN nodes. * With encoding Option 12, the old routers will interprete: + '00' encoding as Not-ECT, and will drop Not-PCN marked packets when congestion is detected. With '00' the encoding for Not-PCN, requiring the same functionality as Not-ECT, the presence of old routers will not affect the performance of PCN functionality. + '01' encoding as ECT(1), which indicates ECN capable and can be remarked to '11' to indicate congestion experienced. For Option 5, the old router can possibly remark AfM to TM. This may or may not be acceptable, depending on the algorithm's Affected Marking functionality. + '10' encoding as ECT(1), which indicates ECN capable and can be remarked to '11' to indicate congestion experienced. The RFC 3168 ECN CE encoding have the same functionality as the PCN TM encoding, to reduce the offered traffic load. Depending on the PCN algorithm on how AM and TM share the same '11' encoding, this may or may not affect the functionality of PCN. + '11' encoding as CE. The old router should use this encoding to reduce the offered traffic load and should not remark this to any other ECN encoding. Depending on the PCN algorithm on how AM and TM share the same '11' encoding, this may or may not affect the functionality of PCN. The above discussion for Option 12 applies equally for PCN traffic leaked out of the PCN domain and interpreted by RFC 3168 ECN nodes. 3. Concern 3: "How does the possible presence of old routers affect the coexistence of the alternate ECN traffic with competing traffic on the path." If RFC 3168 ECN and PCN traffic are to be treated within a single DiffServ PHB, because with these encoding Chan, et al. Expires August 10, 2008 [Page 21] Internet-Draft Document February 2008 there is no way to differentiate between the ECN packets from the PCN traffic, the metering and marking algorithm used must be totally friendly between ECN and PCN traffic, else they will affect each other in possibly non-acceptable ways. These encoding will work OK with traffic besides ECN because of the use of 'Not-PCN' encoding. 4. Concern 4: "How well does the alternate ECN traffic perform." The performance of the different proposed PCN (alternate ECN) metering and marking algorithms are currently under study with their simulation and study results described by their respective documents. Appendix A.4. Encoding Choice Considerations o If three encoding states need to be separately represented, Option 10 is recommended. o If the marking algorithm allows the AM and TM encoding states be represented using the same bit pattern, Option 11 is recommended. o If the marking algorithm requires the use of Affected Marking encoding state, Option 12 is recommended. For Option 12, alternative NPM bit patterns ('01' or '10') may be used for the AfM purpose. Appendix B. Out-of-Band Channel as Encoding Transport In this type of encoding and transport method the congestion and precongestion information can be encoded using the IPFIX protocol RFC 3955 [18], that is normally used to carry flow-based IP traffic measurements from an observation point to a collecting point. Note that this encoding scheme is denoted in this document as "IPFIX channel". An observation point is a location in a network where IP packets can be observed and measured. A collecting point can be a process or a node that receives flow records from one or more observation points. In the PCN case, each PCN-interior-node will be an IPFIX observation point and the PCN-egress-node will be the IPFIX collecting point. The PCN-interior-node will support the metering process and the flow records. Note that in this case each flow record can be associated with the record of the congestion and pre-congestion metering information associated with each PHB. The PCN-egress-node will then support the IPFIX collecting process, which will receive flow records from one or more congested and pre-congested PCN-interior-nodes. Using this encoding method the encoding modes/states can be Chan, et al. Expires August 10, 2008 [Page 22] Internet-Draft Document February 2008 aggregated and transported to the egress node by using the flow records at regular intervals or at the moment that a congestion and pre-congestion situation occurs. The used transport channel in this case is not the data path but a signaling protocol. Appendix B.1. Benefits of Using Out-Of-Band Channel This encoding scheme does not use the data path for encoding and transport, but it is able to transport the congestion and pre- congestion information associated with the encoding states by using a separate signaling channel. Another benefit of using this encoding scheme is that it is not affecting the end-to-end ECN semantics and therefore the issues and concerns raised in RFC 4774 are not applicable for this encoding scheme. Appendix B.2. Drawbacks of Using Out-Of-Band Channel The "IPFIX channel" encoding mode needs a separate signaling channel for the transport of the congestion and precongestion information from the PCN-interior-nodes towards the PCN-egress-node. The requirement of using an additional channel increases the complexity and influences negatively the performance of the PCN-interior-nodes since each PCN-interior-node needs to support in addition to the data path a separate channel. Appendix C. Current PCN Detection, Marking and Transport Mechanisms This appendix indicates the different available PCN based mechanisms that can be used for congestion and pre-congestion detection and marking used at interior nodes. The requirements and characteristics of such algorithms may influence the encoding and transport of the PCN encoding states. Appendix C.1. Detection, Marking and Transport Mechanisms in CL-PHB Please see draft-briscoe-tsvwg-cl-phb-03.txt [5] for details on the Controlled-Load PHB Algorithm. Appendix C.2. Detection, Marking and Transport Mechanisms in Three State Marking Please see draft-babiarz-pcn-3sm-01.txt [2] for details on the Three State Marking Algorithm. Chan, et al. Expires August 10, 2008 [Page 23] Internet-Draft Document February 2008 Appendix C.3. Detection, Marking and Transport Mechanisms in Single Marking Please see draft-charny-pcn-single-marking-03.txt [3] for details on the Single Marking Algorithm. Appendix C.4. Detection, Marking and Transport Mechanisms in Load Control Marking Please see draft-westberg-pcn-load-control-02.txt [4] for details on the Load Control Algorithm. 8. Informative References [1] Eardley, P., "Pre-Congestion Notification Architecture", draft-ietf-pcn-architecture-03 (work in progress), February 2008. [2] Babiarz, J., Liu, X., Chan, K., and M. Menth, "Three State PCN Marking", draft-babiarz-pcn-3sm-01 (work in progress), November 2007. [3] Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre- Congestion Notification Using Single Marking for Admission and Termination", draft-charny-pcn-single-marking-03 (work in progress), November 2007. [4] Westberg, L., "LC-PCN: The Load Control PCN Solution", draft-westberg-pcn-load-control-02 (work in progress), November 2007. [5] Briscoe, B., "Pre-Congestion Notification marking", draft-briscoe-tsvwg-cl-phb-03 (work in progress), October 2006. [6] Baker, F., Polk, J., and M. Dolly, "DSCPs for Capacity-Admitted Traffic", draft-ietf-tsvwg-admitted-realtime-dscp-03 (work in progress), December 2007. [7] Baker, F. and J. Polk, "MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements", draft-ietf-tsvwg-mlef-concerns-00 (work in progress), February 2005. [8] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [9] Wroclawski, J., "Specification of the Controlled-Load Network Chan, et al. Expires August 10, 2008 [Page 24] Internet-Draft Document February 2008 Element Service", RFC 2211, September 1997. [10] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [11] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [12] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [13] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [14] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [15] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [16] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [17] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [18] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002. [19] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [20] Leinen, S., "Evaluation of Candidate Protocols for IP Flow Chan, et al. Expires August 10, 2008 [Page 25] Internet-Draft Document February 2008 Information Export (IPFIX)", RFC 3955, October 2004. [21] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [22] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006. [23] "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms", Proceedings of SIGCOMM '92 at Baltimore MD, August 1992. [24] "Multilevel Precedence and Pre-emption Service (MLPP)", ITU-T Recommendation I.255.3, 1990. [25] "Economics and Scalability of QoS Solutions", BT Technology Journal Vol 23 No 2, April 2005. Authors' Addresses Kwok Ho Chan Nortel 600 Technology Park Drive Billerica, MA 01821 USA Email: khchan@nortel.com Toby Moncaster BT Research B54/70, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom Email: toby.moncaster@bt.com Chan, et al. Expires August 10, 2008 [Page 26] Internet-Draft Document February 2008 Michael Menth University of Wurzburg Institute of Computer Science Room B206 Am Hubland, Wuerzburg D-97074 Germany Email: menth@informatik.uni-wuerzburg.de Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands Email: g.karagiannis@ewi.utwente.nl Philip Eardley BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom Email: philip.eardley@bt.com Bob Briscoe BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom Email: bob.briscoe@bt.com Chan, et al. Expires August 10, 2008 [Page 27] Internet-Draft Document February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Chan, et al. Expires August 10, 2008 [Page 28]