The IESG has approved the following document: - 'Traffic Selectors for Flow Bindings ' <draft-ietf-mext-binary-ts-04.txt> as a Proposed Standard This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-04.txt Technical Summary This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. Working Group Summary The document has been discussed in depth in the WG. The WG feels that this is an important document and should be published. The main controversy was whether there should be one or more traffic selector format defined. This is one format. There is no objection to this format, but rather some people ask for an additional format. Chairs do not see that as a stopper for this document but it is a related issue that as worth mentioning. Document Quality There is at least on ongoing effort for implementing this specification. There were many reviewers of the document, but especial in depth reviews were provided by Dave Craig, Benjamin Lim, Patrick Stupar, and Basavaraj Patil No MIB review nor media type reviews were needed. Personnel The document shepherd is Marcelo Bagnulo Responsible INT AD is Jari Arkko RFC Editor Note OLD: (K)Start DS - Differential Services This field identifies the first differential services value, from the range of differential services values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. Note that this field is called Type of Service field in [RFC0791]. [RFC3260] then clarified that the field has been redefined as 6 bits DS field and 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [RFC3168]. For the purpose of this specification the DS field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 least significant bits MUST be set to 0 by the sender and ignored by the receiver. NEW: (K)Start DS - Differential Services This field identifies the first differential services value, from the range of differential services values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. Note that this field is called Type of Service field in [RFC0791]. [RFC3260] then clarified that the field has been redefined as 6 bits DS field and 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [RFC3168]. For the purpose of this specification the (K)Start DS field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 least significant bit's value MUST be ignored in any comparision. And change this in Section 3.2: OLD: (G)Start Flow Label This field identifies the first flow label value, from the range of flow label values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. According to [RFC2460] the flow label is 24-bit long. For the purpose of this specification the sender of this option MUST prefix the flow label value with 8-bits of "0" before inserting it in this field. The receiver SHOULD ignore the first 8-bits of this field. (H)End Flow Label If more than one contiguous flow label values need to be matched then this field can be used to indicate the end value of a range starting from the value of the Start Flow Label field. This field MUST NOT be included unless the Start Flow Label field is included. When this field is included the receiver will match all of the flow label values between fields (G) and (H), inclusive of (G) and (H). NEW: (G)Start Flow Label This field identifies the first flow label value, from the range of flow label values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. According to [RFC2460] the flow label is 24-bit long. For the purpose of this specification the sender of this option MUST prefix the flow label value with 8-bits of "0" before inserting it in the (G)Start Flow Label field. The receiver SHOULD ignore the first 8-bits of this field before using it comparisons with flow labels in packets. (H)End Flow Label If more than one contiguous flow label values need to be matched then this field can be used to indicate the end value of a range starting from the value of the Start Flow Label field. This field MUST NOT be included unless the Start Flow Label field is included. When this field is included the receiver will match all of the flow label values between fields (G) and (H), inclusive of (G) and (H). When this field is included, it MUST be coded the same way as defined for (G). And this in Section 3.2: OLD: (M)Start TC - Traffic Class This field identifies the first traffic class value, from the range of traffic class values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. This field is equivalent to the Start DS field in the IPv4 traffic selector in Figure 1. As per [RFC3260], the field is defined as 6 bits DS field and 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [RFC3168]. For the purpose of this specification the TC field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 least significant bits MUST be set to 0 by the sender and ignored by the receiver. NEW: (M)Start TC - Traffic Class This field identifies the first traffic class value, from the range of traffic class values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. This field is equivalent to the Start DS field in the IPv4 traffic selector in Figure 1. As per [RFC3260], the field is defined as 6 bits DS field and 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [RFC3168]. For the purpose of this specification the (M)Start TC field is 8 bits long, where the 6 most significant bits indicating the DS field to be matched and the 2 least significant bit's value MUST be ignored in any comparison. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
