Internet DRAFT - draft-han-netext-nchi-flowmngt
draft-han-netext-nchi-flowmngt
NETEXT WG Y. Han
Internet-Draft KUT
Intended status: Informational B. Ahn
Expires: July 1, 2010 Y. An
Network Research Division, ETRI
December 28, 2009
Network-controlled and Host-initiated Flow Management in PMIPv6
draft-han-netext-nchi-flowmngt-00
Abstract
Multihomed mobile nodes are capable of simultaneous attachment to
multiple access networks. In this case, a PMIPv6-enabled local
mobility anchor should distribute the application traffic to a proper
access network which the mobile nodes wish to receive from. This
document specifies how mobile nodes send their desire to the attached
mobile access gateway, which then relays it to a local mobility
anchor.
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 July 1, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Han, et al. Expires July 1, 2010 [Page 1]
Internet-Draft Host Flow Management in PMIPv6 December 2009
This document is subject to BCP 78 and the IETF Trust's Legal
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Han, et al. Expires July 1, 2010 [Page 2]
Internet-Draft Host Flow Management in PMIPv6 December 2009
1. Introduction
The PMIPv6 (Proxy Mobile IPv6) [RFC5213] protocol provides local
mobility management to a mobile node (MN) without requiring any
modification of the MN. If an MN has multiple interfaces and does
simultaneous attachment to multiple access networks, it is expected
that a proper interface can be chosen by the MN to deliver the data.
For the multihomed MN, the local mobility anchor (LMA) will assign
different home network prefix(es) (HNPs) to multiple interfaces of
the MN and manage the MN's binding state properly. The problem is if
the MN wishes to receive a flow traffic bound to HNP1 through
interface1 (IF1), but LMA does not know such a MN's wish exactly in
real-time manner.
By multiple CoA [RFC5648] and flow identifier
[I-D.draft-ietf-mext-flow-binding] supports, the Mobile IPv6
[RFC3775] is extended to allow the binding of a particular flow to a
care-of address without affecting other flows using the same home
address. In this schemes, an MN itself sends the binding identifier
and the associated flow identifier to the home agent. Therefore, the
home agent becomes to know the exact MN's intention about flow
distribution and each flow of the MN's multiple interfaces can be
separately forwarded according to the binding identifier and the flow
identifier managed in the binding cache.
[I-D.draft-koodli-netext-flow-handover] specifies a protocol between
the LMA and a mobile access gateway (MAG) to handover one or more
service flows from an interface to another. In this scheme, when a
new service flow arrives at the LMA, the LMA verifies whether the
flow is "best-mapped" to MN's interfaces that could serve them. This
verification serves as a flow handover trigger which is delivered to
MAG. While this scheme allows the LMA to have the flow handover
control logic, [I-D.draft-hui-netext-service-flow-identifier] lets a
MAG control the flow handover. The latter document defines a new
option, called Service Flow Identifier option, to carry the service
flow identifier and service flow attributes in the Proxy Binding
Update and Acknowledgement messages. An MAG binds MN's each service
flow to the proper HNP, and notifies the created flow binding
information to LMA.
Although the above proposals specify good network-controlled
protocols to bind service flows to MN's interface, they do not
describe how to receive the MN's intention about flow distribution.
Actually, the pure network-controlled protocol excluding the MN's
involvement completely cannot support such a function. However,
host-controlled MIPv6 does well support it and the home agent can
distribute service flows according to MN's intention in a real-time
Han, et al. Expires July 1, 2010 [Page 3]
Internet-Draft Host Flow Management in PMIPv6 December 2009
manner.
This document specifies how MNs send their intention about flow
distribution to the attached MAG, which then relays it to a local
mobility anchor. The proposed scheme does not violate the PMIPv6's
inherent policy. That is, basic flow mobility management follows the
network-controlled flow managment protocol which will be made as IETF
standard based on [I-D.draft-koodli-netext-flow-handover] and
[I-D.draft-hui-netext-service-flow-identifier], so that creation and
management of flow binding are performed in network-side nodes (MAG
or LMA). There are no messages newly defined in this document. MN
just notifies its intention to MAG by exchanging the existing router
solicitation and advertisement messages with MAG.
2. Terminology
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 RFC 2119 [RFC2119].
The terminology in this document is based on the definitions in
[RFC5213], [RFC5648], and [I-D.draft-ietf-mext-flow-binding].
3. Protocol Operation
In PMIPv6, an MN is not directly involved with mobility management
and the binding information is created and managed by an MAG and the
LMA. Therefore, an MN cannot be also involved with flow binding
creation and management. The LMA or the MAG will perform the
operations based on [I-D.draft-koodli-netext-flow-handover] or
[I-D.draft-hui-netext-service-flow-identifier].
When a flow binding is initially created in network-side, the MAG or
the LMA determines which interface of the MN is "best-mapped" to the
current service flow based usually on the MN policy, which is stored
in somewhere in operator network. When the flow binding information
is exchanged by the MAG and the LMA by using a protocol defined by
[I-D.draft-koodli-netext-flow-handover] or
[I-D.draft-hui-netext-service-flow-identifier], the MAG sends a
router advertisement message to the MN in unicast manner (in PMIPv6,
router advertisement message should be sent in unicase manner). This
router advertisement message carries the created flow identifier and
the corresponding flow information tuple (including the IPv6 HNP/IPv4
HoA, transport protocol port numbers and QoS parameters for uplink
and downlink). When the MN receives such a router advertisement
message, it stores the flow binding information internally.
Han, et al. Expires July 1, 2010 [Page 4]
Internet-Draft Host Flow Management in PMIPv6 December 2009
Sometimes, an MN wishes to move a service flow from the current
interface to other interface. This flow handover can be caused by
the MN-internal decision or user's interim decision, etc. At this
time, the MN sends the router solicitation message to the MAG via the
new interface from which the MN wishes to receive the flow traffic.
In PMIPv6, the MAG acts as the default router on the point-to-point
link shared with the MN. So, the router solicitation message will be
directly sent to the MAG. This router solicitation message carries
the flow identifier and the corresponding flow information tuple of
the service flow which the MN intends to move from the current
interface to the new interface.
When receiving such a router solicitation including service flow
information, MAG does perform the network-controlled flow handover
operations based on [I-D.draft-koodli-netext-flow-handover] or
[I-D.draft-hui-netext-service-flow-identifier].
The following Figure 1 depicts the proposed procedure.
MN-IF1 MN-IF2 Previous MAG New MAG LMA
| | | | |
|-----New Attachment----->| | |
| | |-----------PBU------------>|
| | |<----------PBA-------------|
| | | | |
| | | Network-controlled |
|~~~~New Service Flow~~~~>|<=Flow Binidng Management=>|<~~ New
|<--Router Advertisement--| | | Service
| (Flow Binding Info.) | | | Flow
| | |<~~~~~~Service Flow~~~~~~~>|
|<~~~~~Service Flow~~~~~~>| | |
| | | | |
| | | | |
| | | | |
| |---Router Solicitation-->| Network- |
| | (Flow Binding Info.) | controlled |
| | | |<=== Flow ===>|
| | | | Binding |
| | | | Management |
| | | | |
| | | |<~~~Service~~>|
| |<~~~~~Service Flow~~~~~~>| Flow |
| | | | |
The proposed MN-initiated flow distribution
Figure 1
Han, et al. Expires July 1, 2010 [Page 5]
Internet-Draft Host Flow Management in PMIPv6 December 2009
4. Security Considerations
TBD
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
5.2. Informative References
[I-D.hui-netext-service-flow-identifier]
Hui, M., Chen, G., and H. Deng, "Service Flow Identifier
in Proxy Mobile IPv6",
draft-hui-netext-service-flow-identifier-01 (work in
progress), October 2009.
[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-04 (work in
progress), November 2009.
[I-D.koodli-netext-flow-handover]
Koodli, R. and K. Chowdhury, "Flow Handover for Proxy
Mobile IPv6", draft-koodli-netext-flow-handover-01 (work
in progress), October 2009.
Han, et al. Expires July 1, 2010 [Page 6]
Internet-Draft Host Flow Management in PMIPv6 December 2009
Authors' Addresses
Youn-Hee Han
KUT
Gajeon-Ri, 307, Byeongcheon-Myeon
Cheonan, Chungnam
Korea
Phone: +82 41 560 1486
Email: yhhan@kut.ac.kr
Byung-Jun Ahn
Network Research Division, ETRI
Jeonmin-Dong, Yusung-Go
Deajoen, Chungnam
Korea
Email: bjahn@etri.re.kr
Yoon-Young An
Network Research Division, ETRI
Jeonmin-Dong, Yusung-Go
Deajoen, Chungnam
Korea
Email: yyahn@etri.re.kr
Han, et al. Expires July 1, 2010 [Page 7]
