MEXT Working Group K. Wong
Internet-Draft MUST
Expires: August 21, 2008 A. Dutta (Ed.)
Telcordia
H. Schulzrinne
Columbia Univ.
February 18, 2008
Simultaneous Mobility Problem Statement
draft-wong-mext-simultaneous-ps-00
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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Wong, et al. Expires August 21, 2008 [Page 1]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
Abstract
This document provides a problem statement for simultaneous mobility
in an infrastructure-based mobility environment. It considers what
the simultaneous mobility problem is and describes the conditions
under which it may occur. It also illustrates the occurrence of the
simultaneous mobility problem in the context of different mobility
protocols such as Mobile IPv6. The simultaneous mobility problem
defined here is strictly applied to scenarios when the intermediary
nodes in the core are not mobile.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is simultaneous mobility? . . . . . . . . . . . . . . 3
1.2. Likelihood of Simultaneous Mobility . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Simultaneous Mobility Scenarios . . . . . . . . . . . . . . . 7
4. Applicability of simultaneous mobility . . . . . . . . . . . . 10
4.1. Simultaneous Mobility in Mobile IPv6 . . . . . . . . . . . 10
4.2. Simultaneous mobility in SIP-based mobility . . . . . . . 11
5. Occurrence of Simultaneous Mobility Problems . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Wong, et al. Expires August 21, 2008 [Page 2]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
1. Introduction
We consider mobility of end (or terminal) hosts in an infrastructure-
based network like the global Internet. Simultaneous mobility is the
special case when two end hosts are mobile and each moves away from
one attachment point in the network to another at, or at about, the
same time (we give a more precise definition in Section 1.1).
Although it may not be typical (more typical would be the case when
one of the two hosts moves and the other hosts within the network
remain stationary during that time), such an event will occur in from
time to time, and this must be handled properly by mobility
protocols. The simultaneous mobility problem, when it occurs,
results in the loss of a binding update from a Mobile Host because it
is sent to a previous address of the other Mobile Host that is also
moving at around the same time. Without the introduction of
additional measures to rescue the communications session, this would
be expected to result in the interruption of the communications
session.
1.1. What is simultaneous mobility?
We begin by defining some terms that we will use to define the
simultaneous mobility problem.
Two Mobile Hosts attached to two different points of attachment in
the network are said to be in a communication session if they are
actively exchanging data. A communication session may be in a normal
state or an interrupted state. A session is in a normal state when
data from one Mobile Host is arriving at the right location for the
other Mobile Host, and vice versa. It is in an interrupted state
otherwise. A handoff is a movement of a Mobile Host from a previous
attachment point to a new attachment point, such that the old IP
address does not route to the new attachment point, but a new IP
address is needed to route there. The handoff time is the moment in
time when it changes from being reachable at the previous attachment
point to being not reachable at the previous attachment point. Given
that time is continuous, it is assumed that only one handoff can
occur at any given moment in time, i.e, that handoff times are
unique. Two handoffs are consecutive if neither of the Mobile Hosts
performs another handoff in between the two handoffs. Consecutive
handoffs can be at the same mobile host or between two different
mobile nodes.
We assume that binding updates do not contain information about
future moves of the sending Mobile Host. While two Mobile Hosts are
in a communication session, they get information on the location of
the other Mobile Host only from binding updates. In other words,
they do not actively seek the location of the other Mobile Host, but
Wong, et al. Expires August 21, 2008 [Page 3]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
only passively accept binding updates. Binding updates are sent
directly to the most current known address (known by the sender) of
the intended recipient Mobile Host. In general, the latency for
binding updates to arrive is assumed to be much smaller than the
average inter-handoff time, therefore, it is extremely unlikely that
a binding update would be sent and the recipient Mobile Host would
move twice before the binding update arrives at the previous network
of the recipient.
Then, the simultaneous mobility problem occurs when there are two
Mobile Hosts in a communications session in normal state, and they
both move such that the binding updates that they send to each other
are both lost through belated arrival, and such that the
communications session never returns from interrupted to normal
state, but is ended.
For convenience, we also list some of these definitions in Section 2.
1.2. Likelihood of Simultaneous Mobility
Analysis in [simultaneous-mob4] shows that the likelihood of the
simultaneous mobility problem occuring may be non-trivial, depending
on the handoff latencies involved, and the frequency of handoffs.
Wong, et al. Expires August 21, 2008 [Page 4]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
2. Terminology
Communication session: Two Mobile Hosts attached to two different
points of attachment in the network are said to be in a
communication session if they are actively exchanging data. NB:
We do not attempt to define here what "actively exchanging data"
means. This may depend on the applications, and may be related to
a timer set since the last received packet.
Normal state (of a communication session): A session is in a normal
state when data from one Mobile Host is arriving at the right
location for the other Mobile Host, and vice versa.
Interrupted state (of a communication session): A session is in
interrupted state when it is not in normal state
Handoff: A handoff is a movement of a Mobile Host from a previous
attachment point to a new attachment point, such that the old IP
address does not route to the new attachment point, but a new IP
address is needed to route there. NB: this is sometimes known as
layer-3 handoff, in contrast to so-called layer-2 handoff
Handoff Time: The handoff time of a handoff is the moment in time
when it changes from being reachable at the previous attachment
point to not reachable at the previous attachment point.
Lost Binding Update: A binding update is lost if it does not arrive
at its intended destination. A binding update is "lost through
belated arrival" if it makes a belated arrival and is consequently
lost. NB: a binding update can be lost not necessarily through
belated arrival, but through other possible causes of lost binding
updates, r.g., network congestion, node failure, link failure. A
binding update that has arrived late may also be retrieved by some
other agent in the network without getting lost.
Belated Arrival (of Binding Update): A binding update is considered
to make a belated arrival at a network if the destination Mobile
Host is no longer attached to that network.
Wong, et al. Expires August 21, 2008 [Page 5]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
Consecutive Handoff:
Two handoffs are consecutive (with respect to a pair of mobile
nodes) if neither of the Mobile Hosts performs another handoff in
between the two handoffs.
Wong, et al. Expires August 21, 2008 [Page 6]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
3. Simultaneous Mobility Scenarios
In this section, we describe general simultaneous mobility scenarios
in an infrastructure-based evironment.
Figure 1 depicts the simultaneous mobility scenario of two mobile
hosts in an infrastructure based network. The example core network
in Figure 1 is comprised of backbone routers, border routers and edge
routers. The simultaneous mobility problem arises when Mobile Host 1
(MH 1) moves from one attachment point in domain 1 to another
attachment point in domain 2 for example, while at the same (or
nearly the same) time communicating Mobile Host 2 (MH 2) moves from
one attachment point to another attachment point. The binding update
information that must be passed between Mobile Host 1 and Mobile Host
2 will not reach the other prior to their movement.
Wong, et al. Expires August 21, 2008 [Page 7]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
+--+
| | +--+
|AP| | |
| | Domain B1 | |
| |\ Domain A1 /|AP|
+--+ \ / +--+
/--\ \ / /-\
| | \ /--\ ---/ / \
| MH1| \ | / \ |MH2|
\--/ | R |\ | R | \ /
| /\--/ \ / \ / \+/
| +---+ / \ / --\ |
| | | / \ / \\ |
| |AP | / \----- /----X \ +--+ |
\|/ | |/ //\ \\ // \\ \\| | \|/
x +---+ | R +-----+ R | |AP| X
+---+ \\ // \\ // +--+ --
| | /---- \----X +--+ / \
/-\ | |\ / \ | | | |
/ \ |AP | \ / \ / AP MH2
|MH1| | | \\ /--\ / \ // +--+ | |
\ / +---+ \ |/ \ ---/ \ /
\-/ | R | \ / \ --
/\--/ | R |
/ \ | Domain B2
+---+ / --- \
| |/ Domain A2 \ +--+
| | \| |
|AP | |AP|
+---+ | |
+--+
Figure 1: Simultaneous Mobility Scenario
Figure 2 shows the binding updates between two communicating hosts in
an infrastructure-based environment. In the figure, Host A moves
from domain A1 to domain A2 while host B moves from domain B1 to
Domain B2 giving rise to the simultaneous mobility scenario. Under
certain conditions, the mobiles may lose the binding updates from
each other giving rise to problems encountered by simultaneous
mobility.
Wong, et al. Expires August 21, 2008 [Page 8]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
Domain A2 Domain A1 Domain B1 Domain B2
+------+ +------+ +------+ +------+
| | | | | | | |
| A | |A | |B | |B |
| 2nd | |1st | |1st | |2nd |
+---+--+ +---+--+ +---+--+ +---+--+
| | | |
| | | |
| | IP data traffic| |
| |/ \| |
| X-----------------* |
Mobile | |\ /| |
A | |Binding Update\ | |
moves +-----------+---------------X | | Mobile
| | / | | B
| |Binding Update | | moves
| | / | |
| X----------------+-----------+
| | \ | |
| | | |
| | | |
| | | |
| | | |
Figure 2: Simultaneous Mobility Flow: General Scenario
Wong, et al. Expires August 21, 2008 [Page 9]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
4. Applicability of simultaneous mobility
In this section, we describe how general simultaneous mobility arises
for two different mobility protocols, such as MIPv6 [RFC3775] and
SIP-based mobility [SIPMM] are used in an infrastructure-based
environment. Both the protocols exhibit certain common features,
such as the ability to send binding updates directly.
4.1. Simultaneous Mobility in Mobile IPv6
In this section, we describe how and under what conditions,
simultaneous mobility affects the smooth operation of Mobile IPv6
protocol.
Mobility extensions for Internet Protocol v4 (MIPv4) does not have a
problem with simultaneous mobility. By design, non-moving
Correspondent Hosts are unaware of the mobility of Mobile Hosts. The
home agent of the Mobile Host functions as an anchor point for the
Mobile Host. No matter where the Mobile Host moves, packets for it
always go first to its home network for interception and tunneling by
its home agent. If it turns out that the Correspondent Host is also
mobile, it will also have a home agent and packets from the Mobile
Host will similarly be intercepted and tunneled to the appropriate
network by its home agent. Since both home agents are stationary and
can always be reached through IP routing simultaneous mobility does
present a problem to MIPv4.
Mobile IPv6 however suffers from simultaneous mobility problems
because the binding updates are sent directly to the mobile nodes, as
part of route optimization. In addition Care-of-Test Init (CTI) and
Home-Test Init (HTI) are also sent to the correspondent nodes, as
part of return routability. These increase the vulnerability of
Mobile IPv6 to simultaneous mobiity problems because it increases the
delay before a binding update is sent and before it finally arrives
at the other side. Figure 3 shows an example call flow for
simultaneous mobility problems when applied to MIPv6. In this case,
the return routability procedure for Mobile A is completed before it
sends the binding update, but the binding update is lost. It may
also be the case that both sides are unable to complete return
routability because of simultaneous mobility.
Wong, et al. Expires August 21, 2008 [Page 10]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
Home Home
Domain A Domain B
Domain Domain Domain Domain
A2 A1 +-----+ +-----+ B1 B2
+------+ +------+ |Home | |Home | +------+ +------+
| | | | |Agent| |Agent| | | | |
|A 2nd | |A 1st | |A | |B | | B 1st| |B 2nd |
+------+ +------+ | | | | +---|--+ +---|--+
| | +-----+ +-----+ | |
| | | | | |
| |/ | | \| |
| X------------------------------X |
| |\ | | /| |
| | | | | |
| Register \| | | |
+---------+---------X | | |
Mobile | | /| | | |
A | Care-of-Test Init | \| |
moves +---------+---------+---------+----------X |
from | Home Test Init \| | \| |
domain +---------+---------*---------+----------X |
A1 to | | /| | /| |
domain |/ | Care-of-Test | | |
A2 *---------+---------+---------+----------+ |
|X | |/ Home test | |Mobile
*---------+---------*---------+----------+ |B
|\ | |\ |/ |register |moves
| | | X----------+---------+from
| | | |\ | |domain B1
| / | | | Care-of-test init |to
| X---+---------+---------+----------+---------+domain B2
| \ | | | | |
| | / | |/ Home test init |
| | X-------+---------*----------+---------+
| | \ | |\ | |
| |Binding Update | \ | |
+---------+---------+---------+------X | |
| | | | / | |
Figure 3: Simultaneous Mobility in MIPv6
4.2. Simultaneous mobility in SIP-based mobility
In this section we illustrate how simultaneous mobility problem also
affects the SIP. Session Initiation Protocol (SIP) is a protocol
that enables setting up voice calls, two-way multimedia sessions,
teleconferencing, instant messaging and other types of communication
Wong, et al. Expires August 21, 2008 [Page 11]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
using the Internet. SIP is a protocol in the Application Layer of
the OSI Reference Model to enable the establishment, management and
termination of such real-time communications sessions over an
Internet Protocol (IP) network. SIP is defined by RFC 3261 of the
Internet Engineering Task Force (IETF). SIP negotiates the features
and capabilities of a communication session at establishment of the
session reducing time necessary for setting up communication
sessions. Mobility of the end host is handled very naturally by SIP
using existing SIP signaling mechanisms. For example, to initiate a
session, the SIP INVITE message is sent by the initiating device to
the other device. The extension of SIP to handle mid-session
mobility specifies that when one of the two devices moves, it sends a
re-INVITE message to the other device, informing it of its new
location (e.g., its new IP address). In addition to the re-INVITE
message sent directly to the device that moved (Mobile Host) to the
other device (Correspondent Host), the Mobile Host also registers its
presence in the new network with a SIP server in its home network.
This allows other potential Correspondent Hosts to find the Mobile
Host.
Figure 4 is depicts the flow of data resulting from a mishandling of
simultaneous mobility in SIP. In the basic SIP mobility scheme, when
a Mobile Host moves to a new network, it sends a re-INVITE message to
the Correspondent Host, as well as a REGISTER message to its home
network SIP server. There are two options for the part of the re-
INVITE, i.e., it could go through the inbound proxy of the
Correspondent Host, or it could go directly to the Correspondent
Host. This second option will not work properly if there is
simultaneous mobility of the Mobile Host and the Correspondent Host.
Clearly, if the Correspondent Host moves at the same time, the re-
INVITE may be lost (and similarly, the re-INVITE from the
Correspondent Host to the Mobile Host could also be lost). As the
home SIP severs for both are stationary and always reachable through
IP routing, the registrations are not affected by simultaneous
mobility. It would appear the both hosts could now obtain the new
location of the other party through the SIP servers, analogous to how
the home agent provides such information in MIP. However, in MIP,
the home agent quickly discovers that the Correspondent Host needs
the updated binding information, because data packets from the
Correspondent Host are routed to the home network and intercepted by
the home agent.
In the SIP case, on the other hand, the Correspondent Host may not
immediately contact the SIP sever. Instead the re-INVITE may time-
out and may be tried again several more times to the wrong network by
virtue of its built-in retransmission mechanism. The crucial
difference is that the data path and signaling path are separate in
the case of SIP, unlike that of MIP. For simplicity, automatic
Wong, et al. Expires August 21, 2008 [Page 12]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
retransmissions of lost re-INVITE messages are not shown and neither
are messages like ACK that acknowledge the SIP OK. Simultaneous
mobility of two end-hosts is not usually an issue for pre-session
mobility in SIP. However, during a transition before a SIP session
set-up is complete, simultaneous mobility may present problems. As
shown in FIG. 4, it may so happen that one of the signaling messages
(INVITE, OK, ACK) does not reach the other party and gets lost,
despite the SIP server keeping an up-to-date registration for both
parties.
Home Home domain 2a domain 2b
domain 1B domain1A domain 1 domain 2
+------+ +------+ +------+ +------+ +-----+ +------+
| | | | | | | | | | | |
|MH1 | |MH1 | |SIP1 | |SIP2 | |MH2 | |MH2 |
|2nd | |1st | |Server| |Server| |1st | |2nd |
+---|--+ +---|--+ +---|--+ +---|--+ +--|--+ +---|--+
| | | | | |
| | | | | |
| |/ | | \| |
MH1 | X-------------------------------X/ |
Moves | |\ | | /| |
| |re-INVITE | \| |
+-----------+----------+----------+---------* |
| | | | /| |
| REGISTER | \\| | | |
+-----------+----------* | | |MH2
| | /| | | |Moves
| | / |re-INVITE | | |
| | X--------+----------+---------+---------+
MH1 | | \ | |/ REGISTER |
Moves | | | *---------+---------+
| | | |\ | |
| |Both hosts cannot find each other due to |
| |simultaneous mobility |
| | | | | |
| | | | | |
Figure 4: Simultaneous Mobility in SIP-based environment
Wong, et al. Expires August 21, 2008 [Page 13]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
5. Occurrence of Simultaneous Mobility Problems
In this section, we consider when the simultaneous mobility problem
may or may not occur, and we state some of the results of the
analysis in [simultaneous-mob2]. In these results, the term
"location proxy" shall be used (applied to a Mobile Host) in a broad
sense, to meana network function that is used to locate the Mobile
Host. Different categories of location proxies are described in
[simultaneous-mob2], but the categorization is not needed in this
present draft.
In an infrastructure-based environment, given a pair of consecutive
handoffs, one for each of two mobile nodes in a communications
session in normal state (up till the first handoff), in the absence
of location proxies for either mobile node (or there might be
location proxies but they are not used/involved), any binding update
sent by the earlier moving mobile node will be lost through belated
arrival, if and only if the binding update does not arrive at the
other mobile node before it moves.
Given a pair of consecutive handoffs, one for each of two mobile
nodes in a communications session in normal state (up till the first
handoff), in the absence of location proxies for either mobile node
(or there might be location proxies but they are not used/involved),
if the binding update from the node that moved first is lost through
belated arrival, the binding update from the node that moved second
will also be lost through belated arrival.
Given a pair of consecutive handoffs, one for each of two mobile
nodes in a communications session in normal state (up till the first
handoff), in the absence of location proxies for either mobile node
(or there might be location proxies but they are not used/involved),
the simultaneous mobility problem does not occur if and only if the
binding update from the node that moved earlier reaches the other
node before that node moves.
Simultaneous mobility problem does not occur in MIP if it does not
use Route Optimization. No binding updates are sent directly to
mobile nodes. So, there are none to be lost through belated
arrivals. Instead, Home Agents serve as up-to-date intercepting
location proxies that forward data to the right location as soon as
Mobile IP registration occurs after each handoff.
Wong, et al. Expires August 21, 2008 [Page 14]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
6. Security Considerations
The mobility protocols MIPv6 or SIP can use the existing security
mechanisms designed for each of the protocols for any related
extension.
Wong, et al. Expires August 21, 2008 [Page 15]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
7. IANA Considerations
This document has no actions for IANA.
Wong, et al. Expires August 21, 2008 [Page 16]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
8. Acknowledgments
Authors would like to acknowledge anonymous reviewers of the
simultaneous mobility papers.
Wong, et al. Expires August 21, 2008 [Page 17]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
9. References
9.1. Normative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
9.2. Informative References
[simultaneous-mob1]
Wong, K. and A. Dutta, "Simultaneous Mobility in MIPv6",
Proceedings of EIT 2005 May 2005.
[simultaneous-mob2]
Wong, K., Dutta, A., and H. Schulzrinne, "Simultaneous
Mobility: Analytical Framework, Theorems and Solutions",
Journal of Wireless Communications and Mobile
Computing June 2007.
[simultaneous-mob3]
Kravets, R., Carter, C., and L. Magalhaes, "A cooperative
approach to user mobility", ACM Computer Communications
Review October 2001.
[simultaneous-mob4]
Wong, K. and W. Woon, "Analysis of Simultaneous Mobility
under Asymmetric Conditions", Proceedings of Milcom
2007 October 2007.
[SIPMM] Schulzrinne, H. and E. Wedlund, "Application Layer
Mobility Using SIP", ACM MC2R.
Wong, et al. Expires August 21, 2008 [Page 18]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
Authors' Addresses
Daniel Wong
Malaysia University of Science and Technology
GL 33, Block C, Kelana Square, 17 SS 7/26, Kelana Jaya
Petaling Jaya, Selangor 47400
Malaysia
Phone: +603 7880 1777 x282
Email: dwong@must.edu.my
Ashutosh Dutta
Telcordia Technologies
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 3130
Email: adutta@research.telcordia.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
Wong, et al. Expires August 21, 2008 [Page 19]
Internet-Draft Simultaneous Mobility Problem Statement February 2008
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wong, et al. Expires August 21, 2008 [Page 20]