[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 6088

Network Working Group                                        G. Tsirtsis
Internet-Draft                                               G. Giarreta
Intended status: Standards Track                                Qualcomm
Expires: August 30, 2010                                      H. Soliman
                                                    Elevate Technologies
                                                            N. Montavont
                                                                   IT/TB
                                                       February 26, 2010


                  Traffic Selectors for Flow Bindings
                    draft-ietf-mext-binary-ts-04.txt

Abstract

   This document defines binary formats for IPv4 and IPv6 traffic
   selectors to be used in conjunction with flow bindings for Mobile
   IPv6.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 30, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Tsirtsis, et al.         Expires August 30, 2010                [Page 1]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Traffic Selector Sub-Options . . . . . . . . . . . . . . . . .  5
     3.1.  IPv4 binary traffic selector . . . . . . . . . . . . . . .  5
     3.2.  IPv6 binary traffic selector . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   6.  Aknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19



























Tsirtsis, et al.         Expires August 30, 2010                [Page 2]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Tsirtsis, et al.         Expires August 30, 2010                [Page 3]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


2.  Introduction

   This document defines binary formats for IPv4 and IPv6 Traffic
   Selector sub-options as defined in [I-D.ietf-mext-flow-binding].

   The binary traffic selector format defined here, allows for efficient
   identification of flow(s) based on well known fields in IPv4
   [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP
   [RFC0793] and UDP [RFC0768].










































Tsirtsis, et al.         Expires August 30, 2010                [Page 4]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


3.  Traffic Selector Sub-Options

   [I-D.ietf-mext-flow-binding] defines the format for the traffic
   selector sub-option.

   The following values of the TS Format field, are defined in this
   specification for binary traffic selectors.

   TS Format:

      1 IPv4 binary traffic selector

      2 IPv6 binary traffic selector

3.1.  IPv4 binary traffic selector

   If the TS Format field of the traffic selector sub-option indicates
   "IPv4 binary traffic selector", then the traffic selector is
   formatted as shown below.

   The alignment requirement for this sub-option is:

      4n if A, B, C, D, E, or F is set

      2n if G, H, I, or J is set

      n if K, L, M, N is set
























Tsirtsis, et al.         Expires August 30, 2010                [Page 5]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Sub-opt Type   |  Sub-Opt Len  |   TS Format   |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|B|C|D|E|F|G|H|I|J|K|L|M|N|          Reserved                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (A)Start Source Address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (B)End Source Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (C)Start Destination Address                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (D)End Destination Address                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     (E)Start IPSEC SPI                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      (F)End IPSEC SPI                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   (G)Start Source port        |   (H)End Source port          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   (I)Start Destination port   |   (J)End Destination port     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  (K)Start DS  |  (L)End DS    |(M)Start Prot. | (N) End Prot. |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: IPv4 binary traffic selector

   Flags (A-N)

      Each flag indicates whether the corresponding field is present in
      the message

   (A)Start Source Address

      This field identifies the first source address, from the range of
      32-bit IPv4 addresses to be matched, on data packets sent from a
      corresponding node to the mobile node as seen by the home agent.
      In other words this is one of the addresses of the correspondent
      node.

   (B)End Source Address

      If more than one contiguous source address needs to be matched
      then this field can be used to indicate the end value of a range
      starting from the value of the Start Source Address field.  This
      field MUST NOT be included unless the Start Source Address field
      is included.  When this field is included the receiver will match



Tsirtsis, et al.         Expires August 30, 2010                [Page 6]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


      all of the addresses between fields (A) and (B), inclusive of (A)
      and (B).

   (C)Start Destination Address

      This field identifies the first destination address, from the
      range of 32-bit IPv4 addresses to be matched, on data packets sent
      from a corresponding node to the mobile node as seen by the home
      agent.  In other words this is one of the registered home
      addresses of the mobile node.

   (D)End Destination Address

      If more than one contiguous destination address needs to be
      matched then this field can be used to indicate the end value of a
      range starting from the value of the Start Destination Address
      field.  This field MUST NOT be included unless the Start
      Destination Address field is included.  When this field is
      included the receiver will match all of the addresses between
      fields (C) and (D), inclusive of (C) and (D).

   (E)Start IPSEC SPI - Security Parameter Index

      This field identifies the first 32-bit IPSEC SPI value, from the
      range of SPI 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 defined in [RFC4303].

   (F)End IPSEC SPI - Security Parameter Index

      If more than one contiguous SPI 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 IPSEC SPI field.  This field
      MUST NOT be included unless the Start IPSEC SPI field is included.
      When this field is included the receiver will match all of the SPI
      values between fields (E) and (F), inclusive of (E) and (F).

   (G)Start Source Port

      This field identifies the first 16-bit source port number, from
      the range of port numbers to be matched, on data packets sent from
      a corresponding node to the mobile node as seen by the home agent.
      This is from the range of port numbers defined by IANA
      (http://www.iana.org/assignments/port-numbers)

   (H)End Source Port





Tsirtsis, et al.         Expires August 30, 2010                [Page 7]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


      If more than one contiguous source port numbers 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 Source Port field.  This
      field MUST NOT be included unless the Start Source Port field is
      included.  When this field is included the receiver will match all
      of the port numbers between fields (G) and (H), inclusive of (G)
      and (H).

   (I)Start Destination Port

      This field identifies the first 16-bit destination port number,
      from the range of port numbers to be matched, on data packets sent
      from a corresponding node to the mobile node as seen by the home
      agent.

   (J)End Destination Port

      If more than one contiguous destination port numbers 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 Destination Port field.
      This field MUST NOT be included unless the Start Destination Port
      field is included.  When this field is included the receiver will
      match all of the port numbers between fields (I) and (J),
      inclusive of (I) and (J).

   (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.

   (L)End DS - Differential Services

      If more than one contiguous DS 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 DS field.  This field MUST NOT be
      included unless the Start DS field is included.  When this field
      is included, it MUST be coded the same way as defined for (K).
      When this field is included the receiver will match all of the
      values between fields (K) and (L), inclusive of (K) and (L).



Tsirtsis, et al.         Expires August 30, 2010                [Page 8]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


   (M)Start Protocol

      This field identifies the first 8-bit protocol value, from the
      range of protocol values to be matched, on data packets sent from
      a corresponding node to the mobile node as seen by the home agent.

   (N)End Protocol

      If more than one contiguous protocol 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 Protocol field.  This field
      MUST NOT be included unless the Start Protocol field is included.
      When this field is included the receiver will match all of the
      values between fields (M) and (N), inclusive of (M) and (N).

   Reserved

      Reserved for future use.  These bits MUST be set to zero by the
      sender and ignored by the receiver.

3.2.  IPv6 binary traffic selector

   If the TS Format field of the traffic selector sub-option indicates
   "IPv6 binary traffic selector", then the traffic selector is
   formatted as follows:

   The alignment requirement for this sub-option is:

      8n if A, B, C, or D is set

      4n if E, F, G, or H is set

      2n if I, J, K, or L is set

      n if M, N, O, or P is set



         0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Sub-opt Type   |  Sub-Opt Len  |   TS Format   |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |



Tsirtsis, et al.         Expires August 30, 2010                [Page 9]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


       +                  (A)Start Source Address                      +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  (B)End Source Address                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +               (C)Start Destination Address                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                (D)End Destination Address                     +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     (E)Start IPSEC SPI                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      (F)End IPSEC SPI                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      (G)Start Flow Label                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       (H)End Flow Label                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   (I)Start Source port        |   (J)End Source port          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   (K)Start Destination port   |   (L)End Destination port     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  (M)Start TC  |  (N)End TC    | (O)Start NH   | (P) End NH    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: IPv6 binary traffic selector

   Flags (A-P)




Tsirtsis, et al.         Expires August 30, 2010               [Page 10]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


      Each flag indicates whether the corresponding field is present in
      the message

   (A)Start Source Address

      This field identifies the first source address, from the range of
      128-bit IPv6 addresses to be matched, on data packets sent from a
      corresponding node to the mobile node as seen by the home agent.
      In other words this is one of the addresses of the correspondent
      node.

   (B)End Source Address

      If more than one contiguous source address needs to be matched
      then this field can be used to indicate the end value of a range
      starting from the value of the Start Source Address field.  This
      field MUST NOT be included unless the Start Source Address field
      is included.  When this field is included the receiver will match
      all of the addresses between fields (A) and (B), inclusive of (A)
      and (B).

   (C)Start Destination Address

      This field identifies the first destination address, from the
      range of 128-bit IPv6 addresses to be matched, on data packets
      sent from a corresponding node to the mobile node as seen by the
      home agent.  In other words this is one of the registered home
      addresses of the mobile node.

   (D)End Destination Address

      If more than one contiguous destination address needs to be
      matched then this field can be used to indicate the end value of a
      range starting from the value of the Start Destination Address
      field.  This field MUST NOT be included unless the Start
      Destination Address field is included.  When this field is
      included the receiver will match all of the addresses between
      fields (C) and (D), inclusive of (C) and (D).

   (E)Start IPSEC SPI - Security Parameter Index

      This field identifies the first 32-bit IPSEC SPI value, from the
      range of SPI 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 defined in [RFC4303].

   (F)End IPSEC SPI - Security Parameter Index




Tsirtsis, et al.         Expires August 30, 2010               [Page 11]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


      If more than one contiguous SPI 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 IPSEC SPI field.  This field
      MUST NOT be included unless the Start IPSEC SPI field is included.
      When this field is included the receiver will match all of the SPI
      values between fields (E) and (F), inclusive of (E) and (F).

   (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).

   (I)Start Source Port

      This field identifies the first 16-bit source port number, from
      the range of port numbers to be matched, on data packets sent from
      a corresponding node to the mobile node as seen by the home agent.

   (J)End Source Port

      If more than one contiguous source port numbers 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 Source Port field.  This
      field MUST NOT be included unless the Start Source Port field is
      included.  When this field is included the receiver will match all
      of the port numbers between fields (I) and (J), inclusive of (I)
      and (J).

   (K)Start Destination Port






Tsirtsis, et al.         Expires August 30, 2010               [Page 12]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


      This field identifies the first 16-bit destination port number,
      from the range of port numbers to be matched, on data packets sent
      from a corresponding node to the mobile node as seen by the home
      agent.

   (L)End Destination Port

      If more than one contiguous destination port numbers 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 Destination Port field.
      This field MUST NOT be included unless the Start Destination Port
      field is included.  When this field is included the receiver will
      match all of the port numbers between fields (K) and (L),
      inclusive of (K) and (L).

   (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.

   (N)End TC - Traffic Class

      If more than one contiguous TC 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 TC field.  This field MUST NOT be
      included unless the Start TC field is included.  When this field
      is included, it MUST be coded the same way as defined for (M).
      When this field is included the receiver will match all of the
      values between fields (M) and (N), inclusive of (M) and (N).

   (O)Start NH - Next Header

      This field identifies the first 8-bit next header value, from the
      range of next header values to be matched, on data packets sent
      from a corresponding node to the mobile node as seen by the home
      agent.

   (P)End NH - Next Header




Tsirtsis, et al.         Expires August 30, 2010               [Page 13]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


      If more than one contiguous next header 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 NH field.  This field MUST
      NOT be included unless the Start next header field is included.
      When this field is included the receiver will match all of the
      values between fields (O) and (P), inclusive of (O) and (P).

   Reserved

      Reserved for future use.  These bits MUST be set to zero by the
      sender and ignored by the receiver.








































Tsirtsis, et al.         Expires August 30, 2010               [Page 14]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


4.  Security Considerations

   This draft defines the format of the traffic selector field of a sub-
   option defined for flow bindings [I-D.ietf-mext-flow-binding].  The
   authors have not identified any security concerns pertaining to this
   draft beyond what is already identified in
   [I-D.ietf-mext-flow-binding].












































Tsirtsis, et al.         Expires August 30, 2010               [Page 15]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


5.  IANA Considerations

   1) New TS format values from the "Traffic Selector Format" namespace
   for the Traffic Selector sub-option defined in
   [I-D.ietf-mext-flow-binding].  The following values are requested:

      1 IPv4 Binary Traffic Selector

      2 IPv6 Binary Traffic Selector










































Tsirtsis, et al.         Expires August 30, 2010               [Page 16]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


6.  Aknowledgements

   The authors would like to thank Patrick Stupar and Julien Laganier
   for their contributions to this document.  We would also like to
   thank Benjamin Lim, Dave Craig, Patrick Stupar, and Basavaraj Patil
   for their reviews and comments.













































Tsirtsis, et al.         Expires August 30, 2010               [Page 17]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


7.  References

7.1.  Normative References

   [I-D.ietf-mext-flow-binding]
              Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
              Basic Support", draft-ietf-mext-flow-binding-05 (work in
              progress), February 2010.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

7.2.  Informative References

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.















Tsirtsis, et al.         Expires August 30, 2010               [Page 18]

Internet-Draft     Traffic Selectors for Flow Bindings     February 2010


Authors' Addresses

   George Tsirtsis
   Qualcomm

   Email: tsirtsis@qualcomm.com


   Gerardo Giarreta
   Qualcomm

   Email: gerardog@qualcomm.com


   Hesham Soliman
   Elevate Technologies

   Email: hesham@elevatemobile.com


   Nicolas Montavont
   Institut Telecom / Telecom Bretagne
   2, rue de la chataigneraie
   Cesson Sevigne  35576
   France

   Phone: (+33) 2 99 12 70 23
   Email: nicolas.montavont@telecom-bretagne.eu
   URI:   http://www.rennes.enst-bretagne.fr/~nmontavo//






















Tsirtsis, et al.         Expires August 30, 2010               [Page 19]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/