Internet DRAFT - draft-xia-mipshop-arinfo-ps
draft-xia-mipshop-arinfo-ps
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
<Lastname> 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".
<Xia> 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):
<Xia> 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
<Xia> 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
<Xia> 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
<Xia> 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
<Xia> 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
<Xia> 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.
<Xia> 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.
<Xia> 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.
<Xia> 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.
<Xia> 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.
<Xia> 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.
<Xia> 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
<Xia> 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.
<Xia> Expires February 18, 2007 [Page 16]
