Internet DRAFT - draft-njedjou-netlmm-globalmm-ps
draft-njedjou-netlmm-globalmm-ps
Network Working Group Eric Njedjou
Julien Riera
Internet Draft France Telecom
Expires November 2006 May 2006
Problem Statement for Global IP Mobility Management
draft-njedjou-netlmm-globalmm-ps-01.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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html"
This Internet-Draft will expire on November 2, 2006.
Copyright Notice
Copyright © The Internet Society (2006)
Abstract
This document discusses the problem of global IP mobility
management in a context where some mobile operators and service
providers are looking for adequate solutions to the inter-system
IP mobility problem. The document addresses the specific issue of
moving between IP access domains that use different mobility
management protocols and mechanisms. Indeed this type of movement
would be an important subset of global IP mobility scenarios.
njedjou Expires November 2006 [Page 1]
Internet-Draft problem statement May 2006
Table of Contents
1. Introduction................................................2
2. Terminology.................................................4
3. Abbreviations...............................................6
4. Deployment scenarios considered.............................6
4.1. Movement between different access network systems
assisted with a third party provider......................7
4.2. Movement within an integrated access network provider.......8
5. Issues and problems with Existing global IP mobility
management (gmm)solutions................................10
5.1. Signaling volume over the radio............................10
5.2. Complexity of mobility management procedures...............11
5.3. Complexity of hosts........................................11
5.4. Network initiation of mobility.............................11
5.5. Terminal initiation of mobility............................12
5.6. Mobility between two heterogeneous mobility management
domains owned by a same operator.........................12
5.7. Inter-system mobility in other SDOs........................15
6. Security Considerations....................................15
7. Conclusion.................................................15
8. References.................................................16
9. Acknowledgments............................................16
10. Authors Addresses..........................................16
1. Introduction
Global mobility management protocols have been under design by the
IETF for the past fifteen years or so (assuming the creation of
the Mobile IP Working Group as a start). The basic goal pursued at
the time of starting that effort, was the ability to continue an
IP session when a host IP address had to change. The targeted IP
sessions were those involving a transport level connection.
No other motivation but to achieve session continuity has really
been taken into account so far in defining the existing solutions
for global IP mobility management. Effectively, the main goal has
always been to hide the IP address change from the transport level
as well as from the correspondent node perspective. In such a way,
a host would keep its transport connection opened and continue to
be reachable while moving.
The functions achieved were;
. Updating the network of the host IP configuration change
. Having a mobility anchor node perform the route update (upon
moving node alert) or notify correspondents that the moving
host care-of address had changed
Njedjou Expires November 2006 [Page 2]
Internet-Draft problem statement May 2006
. having a mapping on the host between a current and permanent
address to deliver packet to applications
Solutions as Mobile IP or HIP operate on that pattern.
Actually, global mobility management architectures and protocols
at IP layer have grown in more or less a parallel to those
designed in other SDOs as 3GPP where other considerations were
taken into account aside that of just continuing the session of a
user. Indeed 3GPP would be motivated by other considerations as
for example the need for the provider to control the selection of
the target access network of attachment.
And still, future global mobility systems will tend to marry
existing mechanisms from different standardization actors (IETF,
3GPP, IEEE802…) built with different purposes and motivations.
This tendency will grow even wider as services will move to be
all-IP based and access agnostic.
With the previous picture taking place, there is a growing feeling
that the match between these mobility mechanisms built in these
different SDOs is far from being perfect and suitable. This is
especially true when considering some market oriented requirements
as can have;
. Mobile operators owning several access networks of different
types that they want to make cooperate to provide their
users with global mobility
. Third parties operators that want to provide IP mobility to
customers, regardless of the operators to which these
customers are subscribed for the accesses.
Indeed the fact that an IP session handover has to be seamless
should not be the only motivation when solving the global mobility
problem. What appears as a simple movement actually involves a lot
of external factors. While ensuring seamless continuity for the
user, other objectives are to be fulfilled. Such objectives can be
as numerous as:
. Judiciously using the "newly" available radio capacity
(Wifi, Wimax…) to relieve cellular systems and provide
multimedia services;
. Guaranteeing service level for the users by helping them
determine the best system for the service they want to
access to;
. Optimizing the use of the radio resources (especially on
cellular), so as to dedicate the radio spectrum to serving
more data/voice by lowering the signaling overhead;
. Making integrated (and therefore already composite)
architectures less complex, as well as minimizing protocols
to render overall systems more scalable;
. Lowering requirements and constraints on hosts for an easier
support of inter-system mobility.
Njedjou Expires November 2006 [Page 3]
Internet-Draft problem statement May 2006
Some of the previous bullets points basically require that the
global mobility management system be network initiated/operated
while other could be met independently of the mobility operation
model.
Therefore an IP mobility solution designed to enable the previous
requirements should fit both terminal and network initiation and
operation schemes. So that any service provider would be free to
make the use of the solution they want, according to their
architectures and services.
Most of the listed requirements seem not to be in favor of the
global mobility management solutions as they exist today. The
remainder of this document is dedicated at developing the previous
statement.
2. Terminology
Terminology is an aspect of mobility management that is in
constant change, because of often evolving requirements. The
definitions précised below are wanted consensual enough not to
confuse the reader.
Aggregate router
This is a specific router in an access network acting as its
border router on the core network side.
Care-of-address
In this document, a care-of-address refers to an IP address
temporarily acquired by a mobile host while visiting an IP access
network, irrespective of which global mobility management protocol
the host is running. Therefore, a host may have a care-of-address
without running MIP. Coming revisions of this document might
suggest an alternative expression to avoid ambiguity.
IP location update
This is a generic procedure whereby a host informs a mobility
anchor in the network or a correspondent located anywhere on the
internet that it has a new active care-of-address and therefore a
new IP location. This procedure is called registration in Mobile
IPv4 and re-association in HIP.
Comprehensive Mobility management
Njedjou Expires November 2006 [Page 4]
Internet-Draft problem statement May 2006
RFC 3753 defines local and global mobility management but the
notion of mobility management itself is not defined. For the
purposes of this document, comprehensive mobility management will
be defined as the process of performing and sequencing the
following actions;
. Collect information from terminal, Radio Access Points and
Resource Controllers to assess the need or opportunity for a
handover
. Choose a handover target, as a result of deciding the next
Radio Access Network and Point of attachment based on
collected information, QoS needs and other policies.
. Execute the handover on the terminal. This generally
consists in switching between radio links, preparing the IP
configuration over the new link and performing the IP
location update.
This definition does not make any assumption of which side between
the network and the terminal decides of the handoff target.
Global IP mobility management
IP Mobility management is said to be global in this document
whenever it involves a mobile host that is moving between IP
domains that use different mobility procedures and protocols.
Heterogeneous access networks would basically constitutes such IP
domains. These domains can be part of the same administrative
boundaries, eg an operator integrating several access networks
providers or belong to different network administrations. With
this definition an UMTS/WLAN IP service transition will be global,
as well as will be a movement between a NETLMM operated domain and
a 3GPP LTE domain.
Network global IP mobility management
A global mobility management initiated or operated by the network
Local IP mobility management
Mobility management is said to be local whenever it involves a
mobile host moving
. Within an IP domain using a single mobility management
procedure
. Between two IP domains that use the same mobility management
procedures and protocols.
With this definition, the movement of a host within a Wlan or
Wimax domain will be considered local. Indeed, in such domains,
a single IP mobility management protocol would basically be
used. Also will be considered local, a transition between two
NETLMM domains.
Njedjou Expires November 2006 [Page 5]
Internet-Draft problem statement May 2006
Mobility anchor
A mobility anchor is an IP node that either:
. Performs the forwarding and path update of IP packets
destined to the moving host
. notifies correspondents that the moving host care-of address
has changed
With this definition, a mobility anchor only participates to the
goal of making the moving host reachable. The Home Agent of MIP
and the Rendez-Server of HIP are examples of defined mobility
anchors. However this terminology does not necessarily relates to
these nodes.
Inter-System Mobility Agent
This is a function typically located either in an integrated
access operator network or in the terminal and that helps deciding
of the mobile host target system (step 2 of comprehensive mobility
management) based on several criteria. Such an agent is used in
this document to illustrate the global mobility management
problem.
Considerations associated with selection criteria are clearly out
of scope.
3. Abbreviations
gmm: global IP mobility management
NETLMM: network localized IP mobility management
LTE: Long Term Evolution of the radio access network currently
prepared by 3GPP
MIH: Media Independent Handover. This is a functionality of the
Draft IEEE 802.21 specification
IMS: IP Multimedia Subsytem of 3GPP
4. Deployment scenarios considered
As said earlier, global mobility refers to the movement performed
by a host as it changes its point of attachment from an IP domain
to another that has a different mobility procedure.
Such movements will either occur between two access networks of
different providers or also between two access networks owned by
the same service provider. The problem raised in this document
addresses both categories of movement.
Njedjou Expires November 2006 [Page 6]
Internet-Draft problem statement May 2006
4.1. Movement between different access network systems assisted
with a third party provider.
The following figure depicts a deployment model where a host is
moving between two access networks (as described previously)
operated by different providers. Such providers will usually not
cooperate for the purpose of comprehensive mobility management as
defined earlier, nor cooperate with a third party that will serve
the mobility between those access networks. Such a third party
will typically own the IP mobility anchor.
* * *
* *
+----------+
* | Mobility | *
| Anchor |
* +----------+ *
* * *
*
*
* * *
* *
* Internet *
* *
* * * * *
* *
* *
* *
+-------+ +-------+
|AggR A1| |AggR B1|
+-------+ +-------+
AN A @ @ @ AN B
Provider A @ @ @ Provider B
@ @ @
@ @ @
+-----+ +-----+ +-----+
|AR A1| |AR A2| |AR B1|
+-----+ +-----+ +-----+
* * * * *
* * * * *
* * * * *
* * * * *
/\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\
/ A1 \ / A2 \ / A3 \ / B1 \ / B2 \
------ ------ ------ ------ ------
| |
| |
| |
Njedjou Expires November 2006 [Page 7]
Internet-Draft problem statement May 2006
+--+ +--+
|MN|----------------->|MN|
+--+ +--+
Figure 1: example Deployment scenario for two access networks
owned by different providers
The terminal is in this case, the only entity in good position to
initiate the mobility management functions. Indeed it is the only
node capable of getting access networks information, necessary to
decide of the movement. Global mobility management solutions as
they are specified today (i.e basically host based) well apply to
this deployment model. However, as said earlier, the right
mobility architecture should be able to accommodate all deployment
models and mobility controls schemes.
4.2. Movement within an integrated access network provider
The following figure depicts a classical deployment scenario for
an operator that is owner of several access networks that it can
make cooperate, because of the need to ensure the goals and
requirements as listed in the introduction.
* *
* *
* *
* + ----------+ *
|Inter-System|
* | Mobility | * Operator network
| function |
+ ----------+
* *
+---------- +
* |IP Mobility| *
| Anchor |
* +---------- + *
* *
* * * * *
* *
* *
* *
+-------+ +-------+
|AggR A1| |AggR B1|
+-------+ +-------+
AN A @ @ @ AN B
@ @ @
Njedjou Expires November 2006 [Page 8]
Internet-Draft problem statement May 2006
@ @ @
@ @ @
+-----+ +-----+ +-----+
|AR A1| |AR A2| |AR B1|
+-----+ +-----+ +-----+
* * * * *
* * * * *
* * * * *
* * * * *
/\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\
/ A1 \ / A2 \ / A3 \ / B1 \ / B2 \
------ ------ ------ ------ ------
| |
| |
| |
+--+ +--+
|MN|----------------->|MN|
+--+ +--+
Figure 2: Deployment scenario for an integrated operator
4.2.1. Inter-System Mobility management
In such an integrated operator scenario, the network is in good
position to initiate mobility management. It is specifically able
to watch over the capacity of every system and monitor terminal
conditions so as to take the best decision for the user target. An
Inter-System Mobility function would basically perform this IP
handover preparation.
Specifications as the 802.21 draft would see the MIH Point of
Service into such a function (with a corresponding entity in the
terminal and radio access points). Note that this inter-system
mobility function can be co-located to the node acting as the IP
Mobility anchor.
However these considerations are informative only and out of scope
here. IP mobility is clearly the focus of this document. However
the authors intent is to make the point that IP mobility can not
be discussed regardless of the inter-system mobility architectures
that are likely to be deployed.
4.2.2. Knowledge of host care-of address change by the network
When a core network is able to federate the IP domains,
information can be easily exchanged between these domains and such
a core network, belonging to the provider. Therefore, the current
IP configuration of a host can be known in the provider home
network.
Njedjou Expires November 2006 [Page 9]
Internet-Draft problem statement May 2006
Effectively IP configuration assignment schemes of a provider
would be managed from within the provider home network.
On the event of a handover to another IP access domain of the
integrated provider, the target IP configuration of the host
(including the care-of-address to use) would be prepared in the
home network so that the host would not have to make any
notification back upon receiving that new configuration.
However a mobility anchor would still have to perform the routing
update consequently to the host changing its active IP
connectivity from one domain to another.
Therefore, the explicit IP location update as well as the
necessity to keep association states between hosts and mobility
anchor of existing global mobility solutions (Registration and REA
procedures of MIP or HIP) can be avoided in this model. The next
paragraph precisely describes the problem encountered when
resorting to such an explicit IP location update and association
with a IP mobility anchor.
It is to be made explicitly clear that any specific procedure by
which the network can be aware of the terminal new and old IP
configuration is not assumed. Every implementation of the
deployment model can figure out how they want to get the
information.
5. Issues and problems with Existing global IP mobility management
(gmm)solutions
This paragraph captures the reasons why classical gmm solutions
are problematic with regards to driving requirements as presented
in the introduction.
5.1. Signaling volume over the radio
Global IP mobility management solutions known to date do not
guarantee an efficient use of the radio capacity, especially with
the need to associate to a mobility anchor and perform frequent
explicit re-associations.
Terminals are required to support more and more control planes as
they are becoming convergent. A single terminal would have to
support, multiple radios, as well as multiple authentications
protocols, inter-system mobility, IMS… that all generate fair
amount of signaling.
Aside of IP session continuity, integrated mobility architecture
will also have to address such transitions as VoIP to circuit
switched voice. So will multi-systems terminals. This additional
type of session continuity requires specific mobility anchors that
are different from entities as Home Agents (that can only perform
Njedjou Expires November 2006 [Page 10]
Internet-Draft problem statement May 2006
the switch between two IP legs). Therefore, it is a strong
requirement that signaling overhead from hosts to these different
gateways do not grow as their number or type multiplies.
5.2. Complexity of mobility management procedures
As said in the introduction, simplifying architectures and hosts,
as well as minimizing the protocols is a requirement on the road
to rendering next generation mobility architectures more scalable.
Comprehensive mobility management procedures would basically
require that a mechanism exist to perform the steps as described
in section 2, basically collecting information to prepare a
handover, and indicating the target to the terminal. Solutions for
gmm do not provide these steps, which anyway they are not meant
for. The very problem is that they were not thought to be included
to the comprehensive procedures.
Therefore the gmm mechanisms would usually superpose to the
previous procedures to create complex state machines and heavy
message exchange flows between hosts and the network.
Also, usually the integrated architecture would already have
mobility management states for every activated link (UMTS, Wimax…)
on the terminal. To that, is superposed the global IP mobility
management protocol. This protocol superposition adds
sensitiveness to the overall stability of the architecture. In the
middle of that, the integrated architecture will necessarily have
to support inter-media convergence functions such as the MIH of
802.21.
5.3. Complexity of hosts
Lowering software support requirements on hosts would facilitate
early adoption of seamless mobility by reducing the time to market
for terminals to be IP mobility compatible.
This is already a requirement of NETLMM. However such a
requirement difficulty applies for scenarios where the host has to
move between domains operated by different administrations.
Another example of ongoing standard specification where the
principle to get rid of host support applied is the VCC (VoIP to
Circuit Switched) transition work item carried out in 3GPP. This
item is being addressed with no specific needed support on the
host but native IMS.
5.4. Network initiation of mobility
An integrated deployment model as presented in 3.2 has the ability
to facilitate network initiation of handovers. This brings
guarantee of service level to moving users. Indeed the integrated
Njedjou Expires November 2006 [Page 11]
Internet-Draft problem statement May 2006
provider can monitor the load of a base station before allowing a
user application to move to that point of attachment. Network
initiation also brings assurance that the capacity of the provider
is efficiently spread across the wireless domains.
Initiating an IP handover from the network requires that the re-
association procedure should be initiated by the network. Taking
the MIP example, a host would have to perform the registration
update just after receiving an indication from the network to
switch to a different system. Therefore, a specific requirement on
the MIP stack would be to trigger the registration update exchange
upon indication to switch between links.
Furthermore, as the existing gmm solutions as MIP let it totally
implementation dependant the set of events that trigger the IP
location update procedure, it is practically impossible for all
implementations to have the same state machine for triggering such
a re-association.
Therefore, implementations as would be wanted for network
initiation will have to be featured in a way to perform the re-
association procedure only after a network indication to do so.
Flexibility of standard implementation is often desired but can be
become cumbersome in such a case.
Many integrated operators are building roadmaps for deploying
seamless mobility for IP services with the requirements presented
at the beginning of the document. Because of the previously
identified problem of gmm solutions to date, such operators have
to make specific requests for quotations to smart devices vendors
to design implementations that fit their purposes. This burden
becomes considerable when deployment is considered at a large
scale.
5.5. Terminal initiation of mobility
For terminal initiated mobility scenarios, a similar problem is
present. Despite the fact that it would be an inter-system
mobility agent on the terminal that would decide to pass the
traffic to a different link, the gmm protocol still has to be able
to understand an order to do so.
5.6. Mobility between two heterogeneous mobility management domains
owned by a same operator
Two mobility management domains are said to be heterogeneous
whenever the protocols they run for mobility are different.
An alternative deployment scenario for an integrated provider
willing to offer global mobility would via the aggregation of
several heterogeneous mobility domains anchored to a unique core
network.
Njedjou Expires November 2006 [Page 12]
Internet-Draft problem statement May 2006
Effectively, a mobile operator could deploy WiMax in a hotzone and
LTE all around, with an IP mobility protocol (NETLMM for example)
inside the Wimax zone.
* *
* *
* *
* Operator's *
* Aggregation *
* Network *
* *
* *
* * * *
* *
* *
* *
* * * *
* * * *
* * * *
* MM Domain A * * MM Domain B *
* * * *
* IP based * * 3GPP based *
* * * *
AN A * * * * AN B
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
/\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\
/ A1 \ / A2 \ / A3 \ / B1 \ / B2 \
------ ------ ------ ------ ------
| |
| |
| |
+--+ +--+
|MN|------------------->|MN|
+--+ +--+
Figure 4: Mobility between mobility management domains of a single
operator
As in the scenario of figure 2, the fact that both domains belong
to the same administration, make it possible the exchange of
information for mobility management within the network.
Njedjou Expires November 2006 [Page 13]
Internet-Draft problem statement May 2006
As different localized mobility management protocols would be used
in each access domain, a different mobility protocol will have to
be resorted to for the inter-domain transition.
Again for architecture scalability and host simplicity, it would
not be desirable to multiply such mobility protocols. Therefore,
solutions as NETLMM would certainly better be commoditized for
integrated architectures and made more compliant to global
mobility, so that the hosts and the network do not require any
additional mobility management protocol to achieve the inter-
mobility management domain movement.
Also if it eventually turns out that a host based solution as MIP
is used for the movement from a NETLMM to another mobility
management domain, and especially when these domains are owned by
the same operator, it will not have been very useful to bring new
solutions where the host is not involved.
It is to be made clear that in the case where access domains A and
B are operated by different administrations (eg. NETLMM domain
owned by operator A and LTE domain owned by operated B), the
moving host stands as the unique federation entity and would
therefore have to be more implicated in the global mobility
management. Domains owned by several operators will usually not
exchange mobility management information.
* *
* *
*third party*
* mobility *
* anchor *
* *
* Internet *
* *
* * * *
* *
* *
* *
* * * *
* * * *
* * * *
* MM Domain A * * MM Domain B *
* * * *
* IP based * * 3GPP based *
* * * *
AN A * * * * AN B
Provider A * * * * *Provider B
* * * * *
* * * * *
* * * * *
* * * * *
Njedjou Expires November 2006 [Page 14]
Internet-Draft problem statement May 2006
/\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\
/ A1 \ / A2 \ / A3 \ / B1 \ / B2 \
------ ------ ------ ------ ------
| |
| |
| |
+--+ +--+
|MN|------------------->|MN|
+--+ +--+
Figure 5: Mobility between mobility management domains of
different access network providers
As a general observation it is worth reminding that it is making
more and more sense from the market perspective to work on
mobility management solutions meeting the requirement of both
terminal and network modes of mobility management
5.7. Inter-system mobility in other SDOs
3GPP is working on evolved inter-system architectures that could
require global IP mobility protocols for 3GPP to non-G3PP
mobility. Solutions meeting requirements presented in this
document would be particularly adapted to these new architectures.
Available gmm solutions may still work from a pure technical point
of view, but would not meet important requirements as system
scalability, host complexity, signaling volume reduction and many
others discussed earlier.
IEEE 802.21 is defining procedures for managing the transition of
a host across several media. For that purpose, a media independent
handover protocol will have to be supported in the mobility
architecture. Therefore the Internet mobility architecture is
definitely to be adapted to the constraints of inter-media
mobility scenarios that 802.21 is developing.
6. Security Considerations
Security issues linked with existing gmm solutions can not be said
to be an obstacle to deploying architectures with network global
mobility management. Therefore there is no security issue
identified as such. However design goals of a solution to address
the problem described here will have to state precise security
requirements.
7. Conclusion
Njedjou Expires November 2006 [Page 15]
Internet-Draft problem statement May 2006
This document has tried to illustrate the problem of performing IP
mobility with IETF already defined solutions. The context has been
confined to a specific family of deployment scenarios, deemed to
have the potential to grow wide enough to legitimate dedicated
solutions.
It turns out that most of the issues that have been gone through
were especially bad for network global mobility management. It can
be said that existing solutions were thought in a terminal centric
approach and as such match pretty well the needs of the types of
deployments scenarios that where the host would have to initiate
the mobility.
8. References
[MIPV4] "IP Mobility Support", C. Perkins (editor), RFC 2002,
October 1996.
[MIPV6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and
Jari Arkko, RFC 3677, June 2004.
[TERM] "Mobility Related Terminology", J. Manner, M., RFC 3753
June 2004
[HIP] "Host Identity Protocol", P. Jokela (editor), draft-ietf-
hip-base-04, work in progress, October 2005
[NETLMM] "Problem Statement for IP Local Mobility", J. Kemps
(editor), draft-ietf-netlmm-nohost-ps-00.txt, work in progress,
February 2006
[NAH] "Motivation for Network Controlled Handoffs using IP
mobility between heterogeneous Wireless Access Networks", E.
Njedjou, P. Bertin, P. Reynolds, draft-njedjou-inter-an-handoffs-
00.txt, February 2003.
9. Acknowledgments
The authors would like to thank Karine Guillouard, Servane
Bonjour, Jean Christophe Rault from France Telecom for the
valuable inputs they had as reviewers of this document.
10. Authors Addresses
Eric Njedjou
France Telecom
4, rue du CLos Courtel
35512 Cesson Sévigné BP 91226
France
Phone: +33299124878
Email: eric.njedjou@france.telecom.com
Njedjou Expires November 2006 [Page 16]
Internet-Draft problem statement May 2006
Julien Riera
France Telecom
38/40, rue du Général Leclerc
92794 Issy Les Moulineaux Cedex 9
France
Phone: +33145298994
Email: julien.riera@francetelecom.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 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.
Njedjou Expires November 2006 [Page 17]
Internet-Draft problem statement May 2006
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Njedjou Expires November 2006 [Page 18]
