idnits 2.17.1 draft-xia-netext-qos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2009) is 5412 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-12 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Expires: January 1, 2010 Huawei USA 5 June 30, 2009 7 Differentiated Services Support for Proxy Mobile IPv6 8 draft-xia-netext-qos-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 1, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes Quality of Service (QoS) provisioning in a 47 Proxy Mobile IPv6 domain through enabling differentiated services. 48 When a packet is encapsulated in a mobile access gateway (or a local 49 mobility anchor), the differentiated services codepoint (DSCP) field 50 in the outer header is mapped to the priority of a mobile node, or 51 the precedence of an application of the mobile node. Intermediary 52 routers between the mobile access gateway and the local mobility 53 anchor, which forward the packet based on the outer header of the 54 packet, prioritize the packet according to the DSCP value of the 55 outer header. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. IPv4 TOS/IPv6 Traffic Class Overview . . . . . . . . . . . . . 4 62 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Priority Download from AAA . . . . . . . . . . . . . . . . 5 64 4.2. PHP Mapping . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. Encapsulation and Forwarding . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Proxy Mobile IPv6 protocol [RFC5213] specifies network-based IP 76 mobility management support to a mobile node, without requiring the 77 participation of the mobile node in any IP mobility related 78 signaling. The core functional entities for proxy mobile IPv6 are 79 the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). 80 After signalling exchanges between the LMA and the MAG, a bi- 81 directional tunnel is established. 83 The local mobility anchor, being the topological anchor point for the 84 mobile node's home network prefix(es), receives any packets that are 85 sent to the mobile node by any node in or outside the Proxy Mobile 86 IPv6 domain. The local mobility anchor forwards these received 87 packets to the mobile access gateway through the bi-directional 88 tunnel. The mobile access gateway on other end of the tunnel, after 89 receiving the packet, removes the outer header and forwards the 90 packet on the access link to the mobile node. 92 The mobile access gateway acts as the default router on the point-to- 93 point link shared with the mobile node. Any packet that the mobile 94 node sends to any correspondent node will be received by the mobile 95 access gateway and will be sent to its local mobility anchor through 96 the bi-directional tunnel. The local mobility anchor on the other 97 end of the tunnel, after receiving the packet, removes the outer 98 header and routes the packet to the destination. 100 The following is the supported packet encapsulation modes that can be 101 used by the mobile access gateway and the local mobility anchor for 102 tunneling mobile node's IPv6 datagrams and for supporting IPv4 103 transport. 105 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet 107 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet 109 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 110 packet 112 o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP 113 packet with a TLV header. 115 [RFC5213] and its companion document 116 [I-D.ietf-netlmm-pmip6-ipv4-support] details the above 117 encapsulations. IPv6-In-IPv6 is taken as an instance in this 118 document, IPv4 encapsulation is also applicable. 120 [RFC5213] only describes how the ECN (Explicit Congestion 121 Notification) part of IPv6 Traffic Class field being handled at the 122 tunnel entry and exit points, and there is no special consideration 123 on DSCP part of the field. This document describes Quality of 124 Service (QoS) provisioning in a Proxy Mobile IPv6 domain through 125 enabling differentiated services. When a packet is encapsulated in a 126 mobile access gateway (or a local mobility anchor), the DSCP 127 (differentiated services codepoint) field in the outer header is 128 mapped to the priority of a mobile node, or the precedence of an 129 application of the mobile node. Intermediary routers between the 130 mobile access gateway and the local mobility anchor, which forward 131 traffic based on outer headers of the packets, prioritize the packets 132 according to the DSCP values of the outer headers. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. The 139 terminology in this document is based on the definitions in [RFC5213] 141 3. IPv4 TOS/IPv6 Traffic Class Overview 143 Traffic Class field in the IPv6 header [RFC2460] and Type of Service 144 field in the IPv4 header [RFC0791] serve the same function which is 145 available for use by originating nodes and/or forwarding routers to 146 identify and distinguish between different classes or priorities of 147 IPv6/IPv4 packets. [RFC2474] and [RFC3168] further detail Traffic 148 Class/ Type of Service field by defining DSCP and ECN field as 149 following. 151 0 1 2 3 4 5 6 7 152 +-----+-----+-----+-----+-----+-----+-----+-----+ 153 | DS FIELD, DSCP | ECN FIELD | 154 +-----+-----+-----+-----+-----+-----+-----+-----+ 156 DSCP: differentiated services codepoint 157 ECN: Explicit Congestion Notification 159 Regarding how to make use of DSCP field, [RFC2475] defines an 160 architecture for implementing scalable service differentiation in the 161 Internet. At the same time, [RFC2597] specifies a general use 162 differentiated services Per-Hop-Behavior (PHB) Group called Assured 163 Forwarding (AF), while [RFC2598] describes a PHB called Expedited 164 Forwarding. 166 [RFC5213] only describes how the ECN information being handled at the 167 tunnel entry and exit points, and there is no special consideration 168 on DSCP. 170 4. Operations 172 4.1. Priority Download from AAA 174 The priority of subscribers MAY be stored in the mobile node's policy 175 profile which is downloaded from an AAA server to the mobile access 176 gateway once the mobile node attaches to a Proxy Mobile IPv6 Domain 177 and performs access authentication. During the binding update 178 exchange between the mobile access gateway and the local mobility 179 anchor, the local mobility anchor MAY interact with the AAA server in 180 order to access the mobile node's profile and update the remote 181 policy store with the mobility session related information. 183 4.2. PHP Mapping 185 To differientiate subscribers' packets forwarded between the mobile 186 access gateway and the local mobility anchor, the priority of 187 subscribers MUST be mapped to standard Per-Hop-Behavior. Different 188 operators MAY have different mapping, and the following is just as an 189 example. 191 +--------------+-----------------------+ 192 | Priority | PHP | 193 |--------------|-----------------------| 194 | Platinum | EF | 195 | Golden | AF4 | 196 | Silver | AF1 | 197 | Other | BE | 198 +--------------+-----------------------+ 200 Further, packets MAY even be differentiated by application types, for 201 example, VoIP service of Golden subscribers takes priority of web 202 surfing service of Platinum subscribers. 204 4.3. Encapsulation and Forwarding 206 On receiving a packet from a correspondent node with the destination 207 address matching a mobile node's home network prefix(es), the local 208 mobility anchor then 209 o decides the priority based on the mobile node's profile and/or 210 application type, 211 o maps the priority to a pre-defined Per-Hop-Behavior, 212 o and fills the DSCP field of outer IP header when forwarding the 213 packet through the bi-directional tunnel. Intermediary routers 214 between the mobile access gateway and the local mobility anchor, 215 which forward traffic based on the outer header of the packet, 216 prioritize the packet according to the DSCP value of the outer 217 header. 219 A similar processing as above applies when the mobile access gateway 220 forwards upstream packets of the mobile node. 222 5. Security Considerations 224 Security consideration of [RFC5213] applies, and this document does 225 not introduce extra security threats. 227 6. Acknowledgements 229 TBD. 231 7. References 233 7.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 239 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 241 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 242 "Definition of the Differentiated Services Field (DS 243 Field) in the IPv4 and IPv6 Headers", RFC 2474, 244 December 1998. 246 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 247 of Explicit Congestion Notification (ECN) to IP", 248 RFC 3168, September 2001. 250 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 251 (IPv6) Specification", RFC 2460, December 1998. 253 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 254 September 1981. 256 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 257 and W. Weiss, "An Architecture for Differentiated 258 Services", RFC 2475, December 1998. 260 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 261 "Assured Forwarding PHB Group", RFC 2597, June 1999. 263 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 264 Forwarding PHB", RFC 2598, June 1999. 266 7.2. Informative References 268 [I-D.ietf-netlmm-pmip6-ipv4-support] 269 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 270 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12 271 (work in progress), April 2009. 273 Authors' Addresses 275 Frank Xia 276 Huawei USA 277 1700 Alma Dr. Suite 500 278 Plano, TX 75075 280 Phone: +1 972-509-5599 281 Email: xiayangsong@huawei.com 283 Behcet Sarikaya 284 Huawei USA 285 1700 Alma Dr. Suite 500 286 Plano, TX 75075 288 Phone: +1 972-509-5599 289 Email: sarikaya@ieee.org