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 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]