NETLMM Working Group Hong-Ke Zhang
Internet Draft Zhi-Wei Yan
Expires: March 2009 Si-Dong Zhang
Hua-Chun Zhou
Jian-Feng Guan
Beijing Jiaotong University
September 30, 2008
The Extension in NetLMM to Carry Network Condition Information
draft-zhang-netlmm-pmipv6-extension-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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 March 30,2009.
Abstract
The NetLMM WG is specifying Proxy Mobile IPv6 for network-based
localized mobility management (NetLMM), taking basic support for
registration, de-registration and handover into account in the first
protocol release. When a mobile node connects to the access networks
through a sole interface or multiple interfaces, the condition of the
access networks should be considered to improve the performance of
the ongoing applications. According to the normal operation, Local
Mobility Anchor (LMA) can not get enough information to do the
necessary scheduling with Mobile Access Gateway (MAG) and Mobile Node
(MN), such as flow distribution. This document defines a PMIPv6
Zhang et al. Expires March 30, 2009 [Page 1]
Internet-Draft PMIPv6 Extensions September 2008
extension that carries network condition in the form of simple class
indication which is calculated and sent from MAG to LMA in the Access
Technology Type option.
Conventions used in this document
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 [1].
Table of Contents
1. Introduction...................................................2
2. Network condition carrying Extension...........................3
3. Security Considerations........................................4
4. IANA Considerations............................................4
5. References.....................................................4
Author's Addresses................................................5
Intellectual Property Statement...................................5
Disclaimer of Validity............................................6
Copyright Statement...............................................6
Acknowledgment....................................................6
1. Introduction
In PMIPv6, MAG is introduced as a main entity responsible for sending
messages on behalf of a MN whenever the MN hands over within a Local
Mobility Domain (LMD). The messages are sent from a MAG to the LMA
and then the LMA creates a binding to tunnel all packets destined for
an address of the MN to the current attachment point.
The Access Technology Type Option is defined for using it in the
Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a LMA and a MAG. This option is used for exchanging
the type of the access technology using which the mobile node is
currently attached to the network through MAG
With the advent of various radio access technologies and increasing
deployment of sophisticated applications in mobile end systems, LMA
needs more information to perform some effective scheduling in order
to improve the performance of ongoing applications on both the whole
network and MN. However, LMA always can not get the knowledge of the
current network condition from MAG or MN according to the normal
operation of PMIPv6. The extension of the Access Technology Type
Option defined in this document is aimed to let MAG to notify the
network condition information to LMA.
Zhang et al. Expires March 30,2009 [Page 2]
Internet-Draft PMIPv6 Extensions September 2008
2. Network condition carrying Extension
This section defines the network condition carrying extension which
may be used in Access Technology Type Option of PMIPv6. The extension
is sent by MAG and handled by LMA. The scheme of special use of this
extension is out of the scope for this document.
The extended Access Technology Type Option has no alignment
requirement. Its format is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |C| Reserved(R)| ATT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The extended Access Technology Type Option
Type
<IANA>
Length
8-bit unsigned integer indicates the length of the option in octets,
excluding the type and length fields. This field MUST be set to 2.
Network Condition (NC)
A 2-bit field that specifies the network condition corresponding to
the MAG which sends this option. The values (0-3) will be allocated
and managed by IANA. The following values are currently reserved for
the below specified network condition indications.
0: Reserved
1: Poor network condition
2: Medium network condition
3: Good network condition
Access Technology Type (ATT)
Zhang et al. Expires March 30,2009 [Page 3]
Internet-Draft PMIPv6 Extensions September 2008
A 8-bit field that specifies the access technology through which the
mobile node is connected to the access link on the mobile access
gateway. The values (0 - 255) will be allocated and managed by IANA.
The following values are currently reserved for the below specified
access technology types.
0: Reserved
1: Virtual
2: PPP
3: 802.3 (Ethernet)
4: 802.11a/b/g
5: 802.16e
Reserved (R)
This 6-bit field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
3. Security Considerations
This specification introduces new PMIPv6 extensions that are used to
carry network condition information, in the form of classifying
description. The PMIPV6 option messages that carry this extension
MUST be authenticated as described in [2], unless other
authentication methods have been agreed upon. Therefore, this
specification does not lessen the security of PMIPv6.
4. IANA Considerations
This document defines one new PMIPv6 extension to be managed by IANA.
Section 3 defines a new PMIPV6 extension, the Network Condition
Carrying Extension. The type number for this extension is [TBD,
assigned by IANA]. The content and format for this extension is not
specific to the technology of the access network, so if in the future
new access network are added, they may nevertheless be accommodated
within numbering space defined for the network condition Carrying
Extension defined in this document.
5. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Zhang et al. Expires March 30,2009 [Page 4]
Internet-Draft PMIPv6 Extensions September 2008
[2] Gundavelli, et al., "Proxy Mobile Ipv6", RFC5213, August 2008.
Author's Addresses
Hong-Ke Zhang, Zhi-Wei Yan, Hua-Chun Zhou, Si-Dong Zhang, Jian-Feng
Guan
NGI Research Center
Beijing Jiaotong University of China
Phone: +861051685677
Email:hkzhang@bjtu.edu.cn
06120232@bjtu.edu.cn
hchzhou@bjtu.edu.cn
sdzhang@center.njtu.edu.cn
guanjian8632@163.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Zhang et al. Expires March 30,2009 [Page 5]
Internet-Draft PMIPv6 Extensions September 2008
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, The IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang et al. Expires March 30,2009 [Page 6]