One document matched: draft-xia-mipshop-fmip-ptp-01.txt
Differences from draft-xia-mipshop-fmip-ptp-00.txt
Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: January 6, 2008 Huawei USA
July 5, 2007
Fast Handovers for Mobile IPv6 Operation on Point-to-Point Links
draft-xia-mipshop-fmip-ptp-01
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 January 6, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Xia & Sarikaya Expires January 6, 2008 [Page 1]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
Abstract
The FMIPv6 specification currently does not explicitly define the
operation over Point-to-Point links. In this document we define
FMIPv6 operation over the point-to-point links, especially we propose
mechanism for assigning unique prefixes to the MN by the PAR. Three
different solutions are proposed. A new access router dynamically
assigns a unique prefix called dedicated prefix to any MN that is
performing a handover. Alternatively, the previous access router
sends an aggregate prefix of a new access router to MN for
formulating NCoA, and only when handover takes place, the new access
router assigns a dedicated prefix to MN and configures a NCoA for the
MN. Lastly, MN is allowed to generate a special NCoA without any
specific prefix information, and only when handover takes place, the
new access router assigns a dedicated prefix to MN for NCoA
formulation. Both reactive and predictive modes of FMIPv6 are
explained.
Xia & Sarikaya Expires January 6, 2008 [Page 2]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. FMIPv6 Operation on Point-to-Point Links . . . . . . . . . . . 6
4.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Applicability of Solutions . . . . . . . . . . . . . . . . 9
5. HI and Hack Extension . . . . . . . . . . . . . . . . . . . . 9
5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative references . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Xia & Sarikaya Expires January 6, 2008 [Page 3]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
1. Introduction
Fast handovers for Mobile IPv6 (FMIPv6)
[I-D.ietf-mipshop-fmipv6-rfc4068bis] aims at reducing the handover
latency by reducing the time to configure a new care-of address (CoA)
for a mobile node (MN). In FMIPv6, MN formulates a prospective new
CoA (NCoA) when it is still present on the previous access router
(PAR)'s link.
[I-D.ietf-16ng-ipv6-link-model-analysis] provides different IPv6 link
models that are suitable for 802.16 based networks and provides
analysis of various considerations for each link model and the
applicability of each link model under different deployment
scenarios. [I-D.ietf-16ng-ipv6-over-ipv6cs] specifies the addressing
and operation of IPv6 over the IPv6 specific part of the packet
convergence sublayer of IEEE Std 802.16e [802.16e], and Point-to-
Point Link Model is recommended. Also, 3GPP and 3GPP2 have earlier
adopted the point-to-point link model based on the recommendations in
[RFC3314].
In this document, we first explain the problems associated with
FMIPv6 on point-to-point links followed by a detailed explanation of
the modified FMIPv6 operation on point-to-point links.
In Section 3 we describe why the point-to-point link address
formation procedures are needed in FMIPv6, in Section 4 we define
various procedures NAR can use to assign per-MN prefixes in point-to-
point links and in Section 5 we define necessary messages/option for
the operation in Section 4.
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 [RFC2119].
The terminology in this document is based on the definitions in
[I-D.ietf-mipshop-fmipv6-rfc4068bis], in addition to the ones
specified in this section.
Point-to-Point Link Model: In this model, a set of MAC transport
connections between an MN and an AR are treated as a single link.
Each link is allocated a separate, unique prefix or a set of
unique prefixes by the AR. Please refer to
[I-D.ietf-16ng-ipv6-link-model-analysis] for detail. In this
model, a host's only neighbor is its default router.
Xia & Sarikaya Expires January 6, 2008 [Page 4]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
Aggregate Prefix: In Point-to-Point Link Model, AR should broadcast
the prefixes (MNs route information) dynamically upstream, and
this causes high routing protocol traffic (IGMP, OSPF, etc.). To
solve the problem, route aggregation should be used. For example,
each AR can be assigned a /48 prefix, while an MN's /64 prefix is
derived from the /48 prefix extension. The main, higher-level
prefix is called the Aggregate Prefix. An AR only broadcasts the
aggregate prefix upstream.
Dedicated Prefix: A unique prefix used by MN in Point-to-Point Link
Model.
Provisional NCoA: The prefix part of the NCoA is an aggregate prefix
or a special prefix.
Modified NCoA: The prefix part of the NCoA is a dedicated prefix.
3. Problem Statement
The following are operations as per
[I-D.ietf-mipshop-fmipv6-rfc4068bis]:
o Movement detection. The protocol enables an MN to quickly detect
that it has moved to a new subnet by providing the new access
point and the associated subnet prefix information when the MN is
still connected to its current subnet. For instance, an MN may
discover available access points using link-layer specific
mechanisms (i.e., a "scan" in WLAN) and then request subnet
information corresponding to one or more of those discovered
access points. An MN sends a Router Solicitation for Proxy
Advertisement (RtSolPr) to its access router to resolve one or
more Access Point Identifiers to subnet-specific information. In
response, the access router sends a Proxy Router Advertisement
(PrRtAdv) message containing one or more [AP-ID, AR-Info] tuples,
which an MN can use in readily detecting movement: when attachment
to an access point with AP-ID takes place, the MN knows the
corresponding new router's coordinates including its prefix, IP
address, and L2 address.
o NCoA configuration. AR-Info contains an access router's L2 and IP
addresses, and the prefix valid on the interface to which the
Access Point (identified by AP-ID) is attached. With the prefix
provided in the PrRtAdv message, the MN formulates a prospective
NCoA.
In Point-to-Point link model, each MN has one or more dedicated
prefixes, that is, different MNs have different prefixes. The
prefixes could be allocated dynamically. When an MN attaches to an
Xia & Sarikaya Expires January 6, 2008 [Page 5]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
AR, the AR should delegate one or more dedicated prefixes for it;
when the MN detaches from the AR, the MN's prefixes are released, and
can be reused by other MNs. The number of unique prefixes in this
operation can be huge.
NCoA formulation process in point-to-point links depends on the type
of prefix offered in AR-Info. [I-D.ietf-mipshop-fmipv6-rfc4068bis]
does not specify such dependencies. If a dedicated prefix is
offered, then PAR SHOULD request the dedicated prefix from NAR and
the prefix SHOULD be reclaimed if MN does not complete the handover.
If an aggregate prefix is offered, then a modified NCoA SHOULD be
formulated from the dedicated prefix.
After NCoA is formulated from a dedicated prefix, other operations
such as proxying NCoA with proxy neighbor cache at the NAR and
duplicate address detection need to be specified. This is also
missing in [I-D.ietf-mipshop-fmipv6-rfc4068bis].
In short, FMIPv6 operation on point-to-point (p2p) links needs to be
defined. We next define the operations related to NCoA formulation
on point-to-point links.
4. FMIPv6 Operation on Point-to-Point Links
Three different solutions are proposed.
4.1. Solution 1
The simplest fix to the problem described in the previous section is
as follows: NARs assign a unique prefix to each MN that could
handover under this NAR. This prefix will be included in AR-Info.
PAR sends this prefix in the PrRtAdv message. In the PrRtAdv
message, A-bit and L-bit MUST be turned on.
New FMIPv6 message exchange is introduced for PAR to ask for MN's
dedicated prefix as shown in Figure 1. In
[I-D.ietf-mipshop-fmipv6-rfc4068bis], HI is assumed to be sent after
the FBU for handover indication. Here, modified of HI/Hack messages
are used for prefix request/response. Details are described in
Section 5.
The new AP-ID is included in RtSolPr for PAR to locate the
corresponding NAR.
NAR MAY use DHCP prefix delegation (PD) to request/ release prefixes
from a DHCP server. NAR collocated with DHCP Client MAY use the
signaling defined in [I-D.sarikaya-16ng-prefix-delegation] after
Xia & Sarikaya Expires January 6, 2008 [Page 6]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
being triggered by the HI for prefix request. NAR MAY also use AAA
prefix delegation (PD) to request/ release prefixes for this MN from
an AAA server. NAR collocated with AAA Client MAY use the signaling
defined in [I-D.sarikaya-16ng-prefix-delegation] after being
triggered by the HI message for prefix request.
MN PAR NAR DHCP/AAA Server
| | | |
|------RtSolPr------->| | |
| | HI(Prefix Request) | |
| |------------------------->|Prefix |
| | |-Request->|
| | |<-Reply---|
| | HAck(Prefix Response) | |
| |<-------------------------| |
|<-----PrRtAdv--------| | |
| | |No FBU |
| | |Release |
| | |Prefix |
|------FBU----------->|--------HI--------------->| |
| |<------HAck---------------| |
| <--FBack---|--FBack---> | |
disconnect forward | |
| packets=====================>| |
| | | |
| | | |
connect | | |
| | | |
|--------- UNA --------------------------------->| |
|<=================================== deliver packets |
| | |
Figure 1: Prefix Signaling
In Network-initiated Handover scenario, there isn't specific RtSolPr
to trigger PAR to request a prefix. In this case, implementation
specific trigger SHOULD be used by PAR to send HI for prefix request.
4.2. Solution 2
The main idea of this solution is to include an aggregate prefix in
the AR-Info and the MN then uses this prefix to formulate NCoA. We
call it provisional NCoA. Each aggregate prefix advertised by the
candidate NARs MUST be unique.
The following adaptation can be used in predictive mode of FMIPv6:
Xia & Sarikaya Expires January 6, 2008 [Page 7]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
o An MN receives aggregate prefix in AR-Info of PrRtAdv, and
formulates its provisional NCoA according to [RFC2462], [RFC3041]
or other mechanisms. Then, the MN sends FBU message to PAR with
NCoA option, link layer information of MN, and so on. The PAR
sends this information to an NAR in HI message. In order to
determine the NAR's address for the HI message, the PAR can
perform longest prefix match of NCoA (in FBU) with the prefix list
of neighboring access routers.
o HI message defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] is
extended here. A Code value of 3 is defined Section 5.1.
o On receiving the HI, NAR processes the message as per
[I-D.ietf-mipshop-fmipv6-rfc4068bis] if the Code value is not 3.
Otherwise, the NAR allocates one or more dedicated prefixes for
the MN based on it's link-layer information contained in HI
message. NAR generates a new NCoA by replacing the provisional
NCoA's prefix part with the dedicated prefix.
o The modified NCoA is then delivered to the MN in the NCoA field of
HAck/FBack messages. MN MUST use the modified NCoA.
The following adaptation can be used in the reactive mode of FMIPv6:
o MN sends UNA to NAR. The source address of UNA is the provisional
NCoA. If the prefix of the NCoA in the UNA message is not an
aggregate prefix, the NAR processes the message as per
[I-D.ietf-mipshop-fmipv6-rfc4068bis]. Otherwise, the NAR assigns
one or more prefixes for the MN based on Link-Layer Address (LLA)
option in the UNA. NAR MAY use DHCP/AAA protocol to request/
release prefixes for this MN from a DHCP/AAA server triggered by
UNA using [I-D.sarikaya-16ng-prefix-delegation]. A modified NCoA
is formulated by replacing the provisional NCoA's prefix part with
the dedicated prefix. The NAR MUST send a Router Advertisement
with the NAACK option in which it includes the modified NCoA to
the source IP address present in UNA. The MN MUST use the
modified NCoA. NAR MAY advertise more dedicated prefixes to MN in
subsequent RAs.
o MN sends the FBU to the PAR with source address set to the
modified NCoA.
4.3. Solution 3
There are two main functions for PrRtAdv and RtSolPr exchange. One
is fast movement detection, and the other is prefix acquisition for
NCoA formulation [I-D.ietf-mipshop-fmipv6-rfc4068bis].
In this solution, RtSolPr is not necessary, while PrRtAdv is only
used for fast movement detection. An unsolicited PrRtAdv is used to
inform the MN about geographically adjacent ARs without the MN having
to explicitly request that information. This can reduce the amount
of wireless traffic required for the MN to obtain a neighborhood
Xia & Sarikaya Expires January 6, 2008 [Page 8]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
topology map of links and ARs. When attachment to an access point
with AP-ID takes place, the MN knows the corresponding new router's
co-ordinates including its IP address and L2 address, and thus MN can
decide to attach to the NAR or not.
MN initiates fast handover procedure once movement detection occurs.
At first, MN formulates a provisional NCoA without any information
about it's new prefix in the coming handover, so it uses a special
prefix which could be all-one or a random value to stuff the prefix
part of the NCoA. The special prefix could also be the prefix MN
receives in AR-Info [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The
interface identifier part of the NCoA is calculated according to
[RFC2462], [RFC3041] or other mechanism.
In the predictive mode, MN sends FBU with provisional NCoA from PAR's
link. The new AP-ID is included in FBU for PAR to locate the
corresponding NAR. PAR then sends HI to NAR. HI message defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] is extended here. A Code value
of 3 is defined Section 5.1.
On receiving the HI, NAR processes the message as per
[I-D.ietf-mipshop-fmipv6-rfc4068bis] if the Code value is not 3.
Otherwise, NAR allocates a dedicated prefix for MN, replaces prefix
part of the provisional NCoA and sends HAck in response.
In the reactive mode, MN first sends UNA to NAR. The source address
of UNA is the provisional NCoA. NAR then allocates a dedicated
prefix, replaces the special prefix of the provisional NCoA with the
dedicated prefix, and sends a RA with an NAACK option in which the
modified NCoA is included. The MN SHOULD use the modified NCoA.
Subsequently, MN sends the FBU to the PAR with source address set to
the modified NCoA.
4.4. Applicability of Solutions
Comparing with solution 2 and solution 3, solution 1 has better
compatibility with the specification defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis], even though there are two new
messages exchanged between ARs.
5. HI and Hack Extension
5.1. HI Extension
The Handover Initiate (HI)defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] is an ICMPv6 message sent by an
Access Router (typically PAR) to another Access Router (typically
Xia & Sarikaya Expires January 6, 2008 [Page 9]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
NAR) to initiate the process of a MN's handover.
In this document, HI is extended with two new code values:
o In [I-D.ietf-mipshop-fmipv6-rfc4068bis], the PAR uses a Code value
of 0 when it processes an FBU with PCoA as source IP address,
while uses a Code value of 1 when it processes an FBU whose source
IP address is not PCoA. A new Code value of 2 is used for
dedicated prefix request. Dedicated Prefix Option defined in
Section 5.3 MAY be included. NAR allocates dedicated prefix based
on the prefix preference in the option. If the option is not
included, NAR allocates prefix according it's discretion.
o A new code value of 3 is used by PAR to indicate NAR allocating a
dedicated prefix for MN, replacing prefix part of the provisional
NCoA to formulate a modified NCoA, and sending HAck in response in
Solution 2 or Solution 3.
5.2. HAck Extension
Handover Acknowledgment message defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] is a new ICMPv6 message that
MUST be sent (typically by NAR to PAR) as a reply to the Handover
Initiate message. In this document, HAck is extended to respond to a
dedicated prefix request.
o One new Code value is defined. Here, a Code value of 6 is used
for dedicated prefix response.
o Dedicated Prefix Option defined in Section 5.3 MUST be included
for prefix delegation.
5.3. Dedicated Prefix Option
This option is of the form shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Xia & Sarikaya Expires January 6, 2008 [Page 10]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
Figure 2: Dedicated Prefix Option
Type To be assigned by IANA
Length The length of the option in units of 8 octets.
Prefix Length
8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges from 0
to 128.
Option-Code
1 Dedicated Prefix
Lifetime 32-bit unsigned integer. The length of time in seconds
(relative to the time the packet is sent). A value of
all one bits (0xffffffff) represents infinity.
Prefix An IP address or a prefix of an IP address. MN uses it
prefix to formulate NCoA
6. Security Considerations
FMIPv6 operation on point-to-point links does not introduce any new
security threats and the security provided by FMIPv6 applies
completely.
7. IANA consideration
This document extends existing HI/HAck messages, new Code values need
to be assigned by IANA.
The document defines one new Mobility Option which needs type
assignment from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:
1. Dedicated Prefix Option described in Section 5.3.
8. Acknowledgements
The authors would like to thank Heejin Jang, Daniel Park and Rajeev
Koodli for valuable comments.
Xia & Sarikaya Expires January 6, 2008 [Page 11]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mipshop-fmipv6-rfc4068bis]
Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fmipv6-rfc4068bis-01 (work in
progress), March 2007.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
9.2. Informative references
[802.16e] Institute of Electrical and Electronics Engineer,
"Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE 802.16e/D12.
[I-D.ietf-16ng-ipv6-over-ipv6cs]
Patil, B., "IPv6 Over the IP Specific part of the Packet
Convergence sublayer in 802.16 Networks",
draft-ietf-16ng-ipv6-over-ipv6cs-09 (work in progress),
April 2007.
[I-D.ietf-16ng-ipv6-link-model-analysis]
Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
based Networks",
draft-ietf-16ng-ipv6-link-model-analysis-03 (work in
progress), February 2007.
[I-D.sarikaya-16ng-prefix-delegation]
Sarikaya, B. and F. Xia, "Using DHCPv6 and AAA Server for
Mobile Station Prefix Delegation",
draft-sarikaya-16ng-prefix-delegation-01 (work in
progress), March 2007.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
Xia & Sarikaya Expires January 6, 2008 [Page 12]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires January 6, 2008 [Page 13]
Internet-Draft FMIPv6 over Point-to-Point Links July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Xia & Sarikaya Expires January 6, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 07:20:31 |