idnits 2.17.1 draft-han-netext-nchi-flowmngt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 28, 2009) is 5231 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-ietf-mext-flow-binding' is mentioned on line 140, but not defined == Missing Reference: 'I-D.draft-koodli-netext-flow-handover' is mentioned on line 180, but not defined == Missing Reference: 'I-D.draft-hui-netext-service-flow-identifier' is mentioned on line 181, but not defined == Unused Reference: 'I-D.hui-netext-service-flow-identifier' is defined on line 237, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mext-flow-binding' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'I-D.koodli-netext-flow-handover' is defined on line 249, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-hui-netext-service-flow-identifier-01 == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-04 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG Y. Han 3 Internet-Draft KUT 4 Intended status: Informational B. Ahn 5 Expires: July 1, 2010 Y. An 6 Network Research Division, ETRI 7 December 28, 2009 9 Network-controlled and Host-initiated Flow Management in PMIPv6 10 draft-han-netext-nchi-flowmngt-00 12 Abstract 14 Multihomed mobile nodes are capable of simultaneous attachment to 15 multiple access networks. In this case, a PMIPv6-enabled local 16 mobility anchor should distribute the application traffic to a proper 17 access network which the mobile nodes wish to receive from. This 18 document specifies how mobile nodes send their desire to the attached 19 mobile access gateway, which then relays it to a local mobility 20 anchor. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on July 1, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The PMIPv6 (Proxy Mobile IPv6) [RFC5213] protocol provides local 74 mobility management to a mobile node (MN) without requiring any 75 modification of the MN. If an MN has multiple interfaces and does 76 simultaneous attachment to multiple access networks, it is expected 77 that a proper interface can be chosen by the MN to deliver the data. 79 For the multihomed MN, the local mobility anchor (LMA) will assign 80 different home network prefix(es) (HNPs) to multiple interfaces of 81 the MN and manage the MN's binding state properly. The problem is if 82 the MN wishes to receive a flow traffic bound to HNP1 through 83 interface1 (IF1), but LMA does not know such a MN's wish exactly in 84 real-time manner. 86 By multiple CoA [RFC5648] and flow identifier 87 [I-D.draft-ietf-mext-flow-binding] supports, the Mobile IPv6 88 [RFC3775] is extended to allow the binding of a particular flow to a 89 care-of address without affecting other flows using the same home 90 address. In this schemes, an MN itself sends the binding identifier 91 and the associated flow identifier to the home agent. Therefore, the 92 home agent becomes to know the exact MN's intention about flow 93 distribution and each flow of the MN's multiple interfaces can be 94 separately forwarded according to the binding identifier and the flow 95 identifier managed in the binding cache. 97 [I-D.draft-koodli-netext-flow-handover] specifies a protocol between 98 the LMA and a mobile access gateway (MAG) to handover one or more 99 service flows from an interface to another. In this scheme, when a 100 new service flow arrives at the LMA, the LMA verifies whether the 101 flow is "best-mapped" to MN's interfaces that could serve them. This 102 verification serves as a flow handover trigger which is delivered to 103 MAG. While this scheme allows the LMA to have the flow handover 104 control logic, [I-D.draft-hui-netext-service-flow-identifier] lets a 105 MAG control the flow handover. The latter document defines a new 106 option, called Service Flow Identifier option, to carry the service 107 flow identifier and service flow attributes in the Proxy Binding 108 Update and Acknowledgement messages. An MAG binds MN's each service 109 flow to the proper HNP, and notifies the created flow binding 110 information to LMA. 112 Although the above proposals specify good network-controlled 113 protocols to bind service flows to MN's interface, they do not 114 describe how to receive the MN's intention about flow distribution. 115 Actually, the pure network-controlled protocol excluding the MN's 116 involvement completely cannot support such a function. However, 117 host-controlled MIPv6 does well support it and the home agent can 118 distribute service flows according to MN's intention in a real-time 119 manner. 121 This document specifies how MNs send their intention about flow 122 distribution to the attached MAG, which then relays it to a local 123 mobility anchor. The proposed scheme does not violate the PMIPv6's 124 inherent policy. That is, basic flow mobility management follows the 125 network-controlled flow managment protocol which will be made as IETF 126 standard based on [I-D.draft-koodli-netext-flow-handover] and 127 [I-D.draft-hui-netext-service-flow-identifier], so that creation and 128 management of flow binding are performed in network-side nodes (MAG 129 or LMA). There are no messages newly defined in this document. MN 130 just notifies its intention to MAG by exchanging the existing router 131 solicitation and advertisement messages with MAG. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 The terminology in this document is based on the definitions in 140 [RFC5213], [RFC5648], and [I-D.draft-ietf-mext-flow-binding]. 142 3. Protocol Operation 144 In PMIPv6, an MN is not directly involved with mobility management 145 and the binding information is created and managed by an MAG and the 146 LMA. Therefore, an MN cannot be also involved with flow binding 147 creation and management. The LMA or the MAG will perform the 148 operations based on [I-D.draft-koodli-netext-flow-handover] or 149 [I-D.draft-hui-netext-service-flow-identifier]. 151 When a flow binding is initially created in network-side, the MAG or 152 the LMA determines which interface of the MN is "best-mapped" to the 153 current service flow based usually on the MN policy, which is stored 154 in somewhere in operator network. When the flow binding information 155 is exchanged by the MAG and the LMA by using a protocol defined by 156 [I-D.draft-koodli-netext-flow-handover] or 157 [I-D.draft-hui-netext-service-flow-identifier], the MAG sends a 158 router advertisement message to the MN in unicast manner (in PMIPv6, 159 router advertisement message should be sent in unicase manner). This 160 router advertisement message carries the created flow identifier and 161 the corresponding flow information tuple (including the IPv6 HNP/IPv4 162 HoA, transport protocol port numbers and QoS parameters for uplink 163 and downlink). When the MN receives such a router advertisement 164 message, it stores the flow binding information internally. 166 Sometimes, an MN wishes to move a service flow from the current 167 interface to other interface. This flow handover can be caused by 168 the MN-internal decision or user's interim decision, etc. At this 169 time, the MN sends the router solicitation message to the MAG via the 170 new interface from which the MN wishes to receive the flow traffic. 171 In PMIPv6, the MAG acts as the default router on the point-to-point 172 link shared with the MN. So, the router solicitation message will be 173 directly sent to the MAG. This router solicitation message carries 174 the flow identifier and the corresponding flow information tuple of 175 the service flow which the MN intends to move from the current 176 interface to the new interface. 178 When receiving such a router solicitation including service flow 179 information, MAG does perform the network-controlled flow handover 180 operations based on [I-D.draft-koodli-netext-flow-handover] or 181 [I-D.draft-hui-netext-service-flow-identifier]. 183 The following Figure 1 depicts the proposed procedure. 185 MN-IF1 MN-IF2 Previous MAG New MAG LMA 186 | | | | | 187 |-----New Attachment----->| | | 188 | | |-----------PBU------------>| 189 | | |<----------PBA-------------| 190 | | | | | 191 | | | Network-controlled | 192 |~~~~New Service Flow~~~~>|<=Flow Binidng Management=>|<~~ New 193 |<--Router Advertisement--| | | Service 194 | (Flow Binding Info.) | | | Flow 195 | | |<~~~~~~Service Flow~~~~~~~>| 196 |<~~~~~Service Flow~~~~~~>| | | 197 | | | | | 198 | | | | | 199 | | | | | 200 | |---Router Solicitation-->| Network- | 201 | | (Flow Binding Info.) | controlled | 202 | | | |<=== Flow ===>| 203 | | | | Binding | 204 | | | | Management | 205 | | | | | 206 | | | |<~~~Service~~>| 207 | |<~~~~~Service Flow~~~~~~>| Flow | 208 | | | | | 210 The proposed MN-initiated flow distribution 212 Figure 1 214 4. Security Considerations 216 TBD 218 5. References 220 5.1. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 226 in IPv6", RFC 3775, June 2004. 228 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 229 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 231 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 232 and K. Nagami, "Multiple Care-of Addresses Registration", 233 RFC 5648, October 2009. 235 5.2. Informative References 237 [I-D.hui-netext-service-flow-identifier] 238 Hui, M., Chen, G., and H. Deng, "Service Flow Identifier 239 in Proxy Mobile IPv6", 240 draft-hui-netext-service-flow-identifier-01 (work in 241 progress), October 2009. 243 [I-D.ietf-mext-flow-binding] 244 Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., 245 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO 246 Basic Support", draft-ietf-mext-flow-binding-04 (work in 247 progress), November 2009. 249 [I-D.koodli-netext-flow-handover] 250 Koodli, R. and K. Chowdhury, "Flow Handover for Proxy 251 Mobile IPv6", draft-koodli-netext-flow-handover-01 (work 252 in progress), October 2009. 254 Authors' Addresses 256 Youn-Hee Han 257 KUT 258 Gajeon-Ri, 307, Byeongcheon-Myeon 259 Cheonan, Chungnam 260 Korea 262 Phone: +82 41 560 1486 263 Email: yhhan@kut.ac.kr 265 Byung-Jun Ahn 266 Network Research Division, ETRI 267 Jeonmin-Dong, Yusung-Go 268 Deajoen, Chungnam 269 Korea 271 Email: bjahn@etri.re.kr 273 Yoon-Young An 274 Network Research Division, ETRI 275 Jeonmin-Dong, Yusung-Go 276 Deajoen, Chungnam 277 Korea 279 Email: yyahn@etri.re.kr