MIPSHOP Sam(Zhongqi) Xia Internet Draft Jian Zhang Expires: February 2007 Hongfei Chen Huawei Technologies Co.,Ltd August 18, 2006 Access Router Information Construction: Problem Statement draft-xia-mipshop-arinfo-ps-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. This document may only be posted in an Internet-Draft. 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 February 18,2007. Abstract This document addresses some issues about how to construct access router information and how to use them in [FMIP]. Firstly, application scenarios are analyzed; and then, interactions between access router information construction and MIH service are discussed in detail. Finally, security consideration is involved. Table of Contents Expires February 18, 2007 [Page 1] Internet-Draft AR-Info Problem Statement August 2006 1. Introduction................................................2 2. Terminology.................................................3 3. Deployment Scenarios for constructing (AP-ID, AR-Info) tuples.4 3.1. Distributed application scenario for construction........4 3.1.1. Construction of the AP-ID knowledge................5 3.1.2. Construction of (AP-ID, AR-Info) tuples............6 3.1.3. Discovery of neighboring network access routers.....6 3.1.4. Selection of (AP-ID, AR-Info) tuples to be exchanged6 3.1.5. Transportation of messages.........................7 3.2. Centralized application scenario for construction........7 3.3. Mixed application scenario for construction.............8 4. Interaction with MIH service................................10 4.1. Relation between MIH services and (AP-ID, AR-Info)......10 4.2. (AP-ID, AR-Info)s transportation consideration..........12 5. Security Considerations.....................................12 6. IANA Considerations........................................12 7. Conclusions................................................13 8. Acknowledgments............................................13 9. References.................................................14 9.1. Normative References...................................14 9.2. Informative References.................................14 Author's Addresses............................................15 Intellectual Property Statement................................15 Disclaimer of Validity........................................15 Copyright Statement...........................................16 Acknowledgment................................................16 1. Introduction The basic Mobile IPv6 Protocol [RFC3775] is designed to deal with node mobility from the perspective of network layer. But, for some real time applications (i.e. Voice over IP and Video over IP), the handover latency is too long to meet with their service continuity requirements. The Fast Mobile IPv6 Protocol [FMIP] has been developed and proposed as a way to minimize the handover latency of Mobile IPv6 Protocol. In [FMIP], some additional signals have been added to basic handover procedure of Mobile IPv6 Protocol so as to shorten the handover time and to smooth the service performance. There are two kinds of handover modes in [FMIP], which are classified based on whether mobile node has finished the IP layer related configuration before attaching to the new link of access router. One kind of mode is called "Predictive Mode" at which IP layer configuration is finished before handover, and the other is called "Reactive mode". Expires February 18, 2007 [Page 2] Internet-Draft AR-Info Problem Statement August 2006 For both of the two handover modes, it is necessary for mobile node to know the information of neighboring access routers abbreviated as "AR-Info" in [FMIP]. The "AR-Info" is comprised of router's L2 address, router's IP address and router's IP prefix. Apart from "AR- Info", mobile node has to know the "AP-ID", the L2 link address of the imminent access point, which can be gotten during scanning processing. As for mobile node, the key knowledge is the (AP-ID, AR- Info) tuple which contains an access router's L2 address and IP address, and the prefix valid on the interface to which the access point (identified by AP-ID) is attached. The [FMIP] has discussed carefully how to use the (AP-ID, AR-Info) tuple to improve the handover performance. But [FMIP] says that the method by which Access Routers exchange information about their neighbors, and thereby allow construction of Proxy Router Advertisements with information about neighboring subnets is outside the scope of this document. So, the aim of this document is to identify the common lines to the possible solutions and to derive the set of functionalities required to build (AP-ID, AR-Info) tuples for Proxy Router Advertisements. 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 [1]. The following terminology and abbreviations are used in this document: Information Centre Entity (ICE): A new network element introduced in centralized (AP-ID, AR-Info) construction scenario, which is in charge of gathering/delivering (AP-ID, AR-Info) tuples from/to every access router. Media Independent Handover (MIH): MIH is a standard developed by IEEE 802.21 Working Group. This standard is used to provide link layer intelligence and other related network information to upper layers to optimize handovers between heterogeneous media. Base Transceiver Station (BTS): Expires February 18, 2007 [Page 3] Internet-Draft AR-Info Problem Statement August 2006 BTS is a L2 device terminating wireless access used in 3G access networks. Its functionality is similar to Base Station in WIMAX and Access Point in WLAN. Access Service Network Gateway (ASN Gateway): ASN Gateway serves as an access router to WIMAX wireless terminals. Packet Data Supporting Node (PDSN): PDSN serves as an access router to CDMA2000 wireless terminals, which locates in CDMA2000 packet core network. 3. Deployment Scenarios for constructing (AP-ID, AR-Info) tuples Three different deployment scenarios are outlined in this section as the following. These scenarios are intended to specify functionality requirements for the candidate solutions, not to specify the architecture of solutions. 3.1. Distributed application scenario for construction +------+ +-------+ +--------+ | AR1 |/_ _ _ \| AR2 |/_ _ _ \| AR3 | | |\ /| |\ /| | +------+ +-------+ +--------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ |AP | |AP | |BS | |BS | |BTS| |BTS| +---+ +---+ +---+ +---+ +---+ +---+ Figure1: Reference model for distributed construction scenario Expires February 18, 2007 [Page 4] Internet-Draft AR-Info Problem Statement August 2006 Figure1 depicts the reference model for heterogeneous network application scenario working at the distributed construction mode of (AP-ID, AR-Info) tuples. In this figure, three access routers with different functionalities are presented. AR1 is an access router for 802.11 WLAN, to which two access points are attach. AR2 has two 802.16 base stations attaching to its different down link, which plays a role of ASN Gateway. AR3 is an access router running in the 3G telecom networks, whose role may be PDSN in CDMA2000 network. AR3 has two Base Transceiver Stations attaching to its access link (in this figure, Base Station Controller connecting BTS and AR is omitted). When Fast Mobile IPv6 Protocol is applied in this heterogeneous network scenario, there are many factors implementing the construction of (AP-ID, AR-Info) tuples, which should be considered carefully. Detailed discussion is as the following. 3.1.1. Construction of the AP-ID knowledge When access router is integrated with wireless interfaces (such as 802.11 interfaces and 802.16 interfaces), it is very easy for access router to get to know L2 address of wireless interfaces. But, for AR1 and AR2 in figure1, the access points and base stations work independently of access router. The access router can not get to know the L2 address of AP/BS's wireless interface easily. In the simpler case, manual configuration can be used to construct the L2 address knowledge of AP/BS for the access router. More sophisticated solution is to run a dynamic discovering protocol by which access router and AP/BS can interwork and deliver useful information to each other. If there is an existing protocol having this kind of ability, it can be used; otherwise new solution needs to be developed. For different networks, the dynamic protocol is different; and the designing of the dynamic protocol is outside the scope of MIPSHOP working group. AR3 is a network node in 3G networks. And BTS in 3G network works differently with that in 802 series network. The great difference is that BTS has no L2 address while AP/BS in 802 series network does have (see [3GFH]). To identify an access network in CDMA2000, the Access Network Identifier (ANID), which is composed of the System ID (SID), Network ID (NID) and Packet Zone ID (PZID) can be used, instead of using L2 address of AP/BS in 802 series wireless network. Because there are many BTSes attaching to the same access router, it is not easy for access router to get the knowledge about ANID. Similarly, both manual configuration and automatic discovering Expires February 18, 2007 [Page 5] Internet-Draft AR-Info Problem Statement August 2006 mechanism can be used to construct the ANID knowledge for the access router. 3.1.2. Construction of (AP-ID, AR-Info) tuples Having gotten to know the information about AP-IDs, the access router has to construct the associations used in Proxy Router Advertisement between AP-IDs and AR-Info. In nature, it's not difficult for access router to construct the associations. No matter what construction mode of AP-IDs is used, AP- ID can be bound to a L3 interface which has its own information absolutely. 3.1.3. Discovery of neighboring network access routers As for construction of (AP-ID, AR-Info) tuples, Figure1 is a distributed reference model. Different access router has to construct the repository of (AP-ID, AR-Info)s independently and serves for the mobile nodes attaching to its link. Before access routers can exchange neighboring network information, they have to know each other. It is very difficult for access router to determine the neighboring network access routers. For different deployment applications, the difference is great. Maybe the access routers at the same geographical location are not neighboring network access routers even though there is a direct link between them (i.e. neighboring routers). And maybe the access routers far from each other are neighboring network access routers even though there are many hops between them. In the simpler case, manual configuration can help access router determine neighboring network access routers. But for the large scale telecom networks, the neighboring network relationship is very complicated. And manual configuration can't be competent with this situation. More sophisticated solution is to use dynamic discovering protocol. There are many factors deserved to be considered carefully, which are outside the scope of this document. 3.1.4. Selection of (AP-ID, AR-Info) tuples to be exchanged In figure1, AR2 has four access sub-networks and AR3 has two. In the real world, maybe there are more sub-networks attaching to the same access router. So it's not necessary for neighboring network access routers to exchange all of the (AP-ID, AR-Info) tuples. More Expires February 18, 2007 [Page 6] Internet-Draft AR-Info Problem Statement August 2006 effective way is only to exchange overlay/neighboring sub-network information. How to determine overlay/neighboring sub-networks is outside the scope of this document. 3.1.5. Transportation of messages Transportation is performed between neighboring network access routers. Different kinds of messages require kinds of service level agreement for transportation. For example, management and control messages should be transported at reliability channel while (AP-ID, AR-Info) bearing messages require a fast and no guaranteed reliability one. Besides, many general transportation functionality should be consider carefully, such as congestion avoidance, reliability, security, fragmentation as well as reordering etc. 3.2. Centralized application scenario for construction Expires February 18, 2007 [Page 7] Internet-Draft AR-Info Problem Statement August 2006 +-----+ | ICE | +-----+ / | \ +------------+ | +-------------+ | | | +------+ +-------+ +--------+ | AR1 | | AR2 | | AR3 | | | | | | | +------+ +-------+ +--------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ |AP | |AP | |BS | |BS | |BTS| |BTS| +---+ +---+ +---+ +---+ +---+ +---+ Figure2: Reference model for centralized construction scenario Figure2 depicts a reference model for centralized construction scenario of (AP-ID, AR-Info). In contrast with Figure1, there is no great difference except that a new node called Information Centre Entity (ICE) is added. The Information Centre is a central repository of (AP-ID, AR-Info) tuples, which aggregates (AP-ID, AR-Info) tuples from every access router and delivers them to the requesting access router. For the centralized construction scenario, there are no new requirements about construction of AP-ID knowledge and (AP-ID, AR- Info) tuples compared with the distributed construction scenario. Introduction of Information Centre makes it unnecessary to run a dynamic discovering protocol of neighboring network access router because access router works together with ICE, instead of with neighboring network access routers. It is very important and useful to determine the (AP-ID, AR-Info) tuples to be exchanged between access router and ICE. Having constructed the (AP-ID, AR-Info) tuples, access router has to select the suitable tuples to be delivered to ICE. Access router can request (AP-ID, AR-Info) tuples from ICE based on AP-IDs; and ICE maybe push the suitable (AP-ID, AR-Info) tuples to a specific access router base on some polices. The transportation requirements for centralized construction scenario are the same as for distributed construction scenario. 3.3. Mixed application scenario for construction Expires February 18, 2007 [Page 8] Internet-Draft AR-Info Problem Statement August 2006 +-----+ | ICE | +-----+ | | +------+ +-------+ +--------+ | AR1 |/_ _ _ \| AR2 |/_ _ _ \| AR3 | | |\ /| |\ /| | +------+ +-------+ +--------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ |AP | |AP | |BS | |BS | |BTS| |BTS| +---+ +---+ +---+ +---+ +---+ +---+ Figure3: Reference model for mixed construction scenario Figure3 depicts a reference model for mixed (distributed and centralized) construction scenario. From functional component perspective, Figure3 is the same as Figure2. In Figure3, only AR2 has established association with ICE while both AR1 and AR2 interwork with AR2. For the mixed construction scenario in Figure3, AR1 and AR3 get neighboring network information from AR2. And AR2 exchanges information with AR1, AR2 and ICE at the same time. In this scenario, AR2 maybe acts as a proxy for AR1 and AR3 to exchange information with ICE. There are no special requirements for the mixed construction scenario compared with the above mentioned two scenarios. 3.4. Others The above mentions scenarios may be applied to the same domain owned by the same operator. How to construct (AP-ID, AR-Info) tuples for access routers owned by different operators needs to be studied further. Expires February 18, 2007 [Page 9] Internet-Draft AR-Info Problem Statement August 2006 4. Interaction with MIH service Media Independent Services, including Event Service, Command Service and Information Service are designed by IEEE802.21 Working Group, which help MIH service user (i.e. mobility management protocol) facilitate the recognition that a handover should take place, discover information on how to make effective handover decisions and expedite handover executing procedure. The Event Service, Command Service and Information Service are defined in [MIH]. And [MIHPS] has proposed the brief definition for these services. In general, MIH services have established an architecture that enables transparent service continuity while mobile node moves between heterogeneous networks; determined a set of handover-enabling functions within the mobility-management protocol stacks of the network elements; and defined additional MAC layer SAPs and associated primitives for each specific access technology. The Information Service of [MIH] can be used to transport and construct (AP-ID, AR-Info) tuples of neighboring access network. [MIH] has defined three kinds of information elements for Information Service. One kind is Link Layer Information Element, which can be used to transport (AP-ID, AR-Info) tuples between two access routers as well as between access router and Information Centre Entity. 4.1. Using MIH IS in distributed construction scenario Figure4 depicts the transportation and construction procedure for (AP-ID, AR-Info) tuples of neighboring network using Information Service. After two neighboring network access routers discover each other, one access router can query the other for specific (AP-ID, AR- Info) tuples; and the other can send the response to the querying access router. Besides the query and response messages, MIH Information service should support the other type of messages, such as "report message" which can be used to transport a bulk of (AP-ID, AR-Info) tuples without active query when access routers discover each other firstly. Expires February 18, 2007 [Page 10] Internet-Draft AR-Info Problem Statement August 2006 +---------+ +---------+ |AR/MIH IS| |AR/MIH IS| +---------+ +---------+ | | |____IS-Query_________\| | /| |/___IS-Response ______| |\ | | | |/___IS-Query__________| |\ | |____IS-Response______\| | /| Figure4: Using MIH IS in distributed construction scenario 4.2. Using MIH IS in centralized scenario Figure5 depicts the transportation and construction procedure of (AP- ID, AR-Info) tuples in centralized construction scenario. In this figure, after AR1 and AR2 have discovered the ICE supporting MIH Information Service, both access routers send the report of own (AP- ID, AR-Info) tuples to ICE. And then, both of them query the (AP-ID, AR-Info) tuples of neighboring networks from ICE. For this scenario, ICE is an central repository of (AP-ID, AR-Info) tuples. Expires February 18, 2007 [Page 11] Internet-Draft AR-Info Problem Statement August 2006 +----------+ +----------+ +----------+ |AR1/MIH IS| |ICE/MIH IS| |AR2/MIH IS| +----------+ +----------+ +----------+ | | | |____IS-Report_______\|/________IS-Report____| | /|\ | |____IS-Query________\|/________IS-Query_____| | /|\ | | | | |/___IS-Response______|_________IS-Reponse__\| |\ | /| | | | Figure5: Using MIH IS in centralized construction scenario 4.3. (AP-ID, AR-Info)s transportation consideration Before transporting Information Service bearing (AP-ID, AR-Info)s, every transportation peer, including access router and ICE, should discover each other at first. For the distributed construction scenario, access router has to discover the peers firstly which provide Information Service; and for the centralized construction scenario, access router has to know the ICE firstly which provide the Information Service. If MIH services cover the peer discovering function, more attention should be paid to this; otherwise, it is necessary to develop a new protocol or to select an existing one so as to cover this function. Even though MIH services provide transportation service, it does not know what to be transported, which depends on the MIH services user (i.e. MIP6 or FMIP). Particularly, it is not easy for access router to determine what tuples should be transported and which access router is the destination in the distributed construction scenario. 5. Security Considerations Construction of (AP-ID, AR-Info) tuples is performed by network infrastructure, especially by access router and ICE, not involving untrusting outer entity. So it is relatively secure. In some cases, neighboring network access routers are owned by the different operators or connected through public network (such as Internet). So, it is necessary for access router to authenticate each other; and the authentication procedure should be protected by a secure channel. At the same time, the messages exchanged among access routers and ICE should be encrypted. 6. IANA Considerations IANA considerations are not applicable for this document. Expires February 18, 2007 [Page 12] Internet-Draft AR-Info Problem Statement August 2006 7. Conclusions This document has outlined three scenarios for constructions of (AP- ID, AR-Info) tuples and raised some issues needed to be considered carefully. This document thinks MIH service can help access router construct and transport (AP-ID, AR-Info) tuples. But some other factors, such as discovering mechanism and content selection method should be considered. 8. Acknowledgments Thank Akbar Rahman from InterDigital Communications, Xiaodong Duan from China Mobile for their kind comments. Expires February 18, 2007 [Page 13] Internet-Draft AR-Info Problem Statement August 2006 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC3775] D. Johnson, C. Perkins, J. Arkko, " Mobility Support in IPv6", RFC3775, June 2004. [MIH] IEEE P802.21/D00.01, Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services. [FMIP] R. Koodli, Ed., "Fast Handovers for Mobile IPv6", RFC4068. [3GFH] H. Yokota, G. Dommety, "Mobile IPv6 Fast Handovers for 3G CDMA Networks", May 4, 2006 9.2. Informative References [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 1583. [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. [MIHPS]: E.Hepworth, S.Sreemanthula, S.Faccin, Y.ohba, "Media Independent Handovers: Problem Statement", June 26, 2006. [NIHOPS]: T.Melia, J.Korhonen, TeliaSonera, R.Aguiar, S.Sreemanthula, V.Gupta, "Network initiated handovers problem statement", June 18, 2006. Expires February 18, 2007 [Page 14] Internet-Draft AR-Info Problem Statement August 2006 [FMIPo802.16] Heejin Jang, Junghoon Jee, Youn-Hee Han, Soohong Daniel Park, Jaesun Cha, "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", April 12, 2006. [DCFMIH] E.Hepworth, R.Hancock, S.Sreemanthula, S.Faccin, "Design Considerations for the Common MIH Protocol Functions", June 19, 2006. Author's Addresses Sam(Zhongqi) Xia HuaWei Bld., No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing P.R. China Phone: 86-10-82836136 Email: xiazhongqi@huawei.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. 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 AND THE INTERNET Expires February 18, 2007 [Page 15] Internet-Draft AR-Info Problem Statement August 2006 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 Internet Society (2006). 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. Expires February 18, 2007 [Page 16]