NETLMM Working Group A. Muhanna
Internet-Draft Nortel
Intended status: Standards Track S. Krishnan
Expires: August 28, 2008 Ericsson
K. Leung
Cisco
B. Patil
Nokia Siemens Networks
February 25, 2008
Proxy MIPv6 Support of Transient Registration
draft-muhanna-netlmm-pmipv6-support-transient-coa-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 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 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
In order for the local mobility anchor to receive and forward uplink
traffic for a mobile node, Proxy Mobile IPv6 base protocol mandates
the LMA to have an active BCE with a registered proxy CoA that is the
Muhanna, et al. Expires August 28, 2008 [Page 1]
Internet-Draft PMIPv6 Support Transient Registration February 2008
other end of the tunnel between the LMA and MAG. In some systems and
during active inter-MAG handoff with traffic that is sensitive to
delay and packet loss, the LMA is required to forward uplink traffic
for the mobile node from the target MAG without completely switching
the tunnel from the source MAG. This document specifies a mechanism
which allows the target MAG to perform transient registration for a
new proxy CoA and the LMA to create a transient BCE for the same
mobile node for a specified period of time while maintaining the
original mobile node's BCE which reference the old pCoA at the source
MAG.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. PMIPv6 Transient Registration Overview . . . . . . . . . . . . 5
4. Transient Registration Option . . . . . . . . . . . . . . . . 6
5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 8
6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10
7. Transient Binding Cache Entries Update . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Muhanna, et al. Expires August 28, 2008 [Page 2]
Internet-Draft PMIPv6 Support Transient Registration February 2008
1. Introduction
Proxy Mobile IPv6 is a network-based mobility protocol which provides
IP mobility for a mobile node without the involvement of the IPv6
host. Whenever a mobile node is attached to a PMIPv6 domain via a
mobility access gateway, it appears to the mobile node as if it is
attached to the same home link and thus the mobile node may think
that it is not roaming away from home. In the case of mobile node
active inter-MAG handoff from the source to the target MAG, the
target MAG usually sends a proxy BU message to the mobile node local
mobility anchor to update the mobile node BCE with a new pCoA. As
soon as the LMA receives and successfully processes the proxy BU from
the target MAG, LMA updates the mobile node BCE with the new care of
address and switch the tunnel to the target MAG.
However, during active inter-MAG handoff scenario, some of the mobile
node uplink traffic may still be in transit through the previous MAG.
In addition, in some active handoff scenarios, it is necessary to
prepare the target MAG prior to completion of link layer handoff
procedures. In some systems, the target MAG will be the recipient of
uplink traffic prior to the completion of the procedure that would
result in the PBU/PBA. Currently and as per PMIPv6 base protocol
[1], LMA routes the mobile node's uplink traffic received from a
tunnel as long as the source IP address of the mobile node's uplink
traffic matches the IP address of the mobile node's registered pCoA
in an active BCE.
This document specifies an enhancement to Proxy MIPv6 base protocol
to support transient registration. This process allows the target
mobile access gateway to request the local mobility anchor to create
a transient binding cache entry with uplink traffic forwarding
capabilities for a specified period of time while still maintaining
the active state for the existing BCE, i.e., sending and receiving
traffic on both directions. Eventually and after a short lived
lifetime, the mobile node transient BCE is updated to regular BCE and
the original regular BCE is removed as described in Section 6
This mechanism is critical for reducing handoff latency and will be
an important parameter for real-time applications such as VoIP. It
is assumed that inter-MAG handoff is carried out with a central
entity that is responsible for the mobile node context transfer
across the source and target MAGs.
Muhanna, et al. Expires August 28, 2008 [Page 3]
Internet-Draft PMIPv6 Support Transient Registration February 2008
2. Conventions used in this document
The keywords "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 [2].
General mobility terminology can be found in [5], [3], and [1]. The
following additional or clarified terms are used in this document:
Proxy BCE (pBCE):
The mobile node BCE that has the same characteristics as the MN
BCE in PMIPv6 base protocol [1].
Transient BCE (tBCE):
The mobile node BCE that is created by the process described in
this document. The tBCE is short lived with a lifetime that is no
more than the transient registration lifetime. When LMA creates
such transient BCE, it allows uplink traffic from the mobile node
while the mobile node is in the process of moving from sMAG to the
tMAG.
Transient Registration (tReg.)
The mechanism which allows the LMA to create a transient BCE for a
specific mobile node with uplink traffic forward capability from a
care-of address different than the current proxy care-of address
that is registered in the mobile node current regular BCE. During
the lifetime of the tBCE, the LMA may forward the mobile node
uplink traffic from both care-of addresses to the internet while
sending the downlink traffic to the source care-of address.
Source MAG (sMAG):
The mobile access gateway that the mobile node is currently
attached to and moving from its area coverage to another MAG.
Target MAG (tMAG):
The mobile access gateway that the mobile node is moving to its
area of coverage and attaches to during an inter-MAG handoff
scenario.
Muhanna, et al. Expires August 28, 2008 [Page 4]
Internet-Draft PMIPv6 Support Transient Registration February 2008
Source proxy Care-of Address (s-pCoA):
The mobile node proxy care-of address that is hosted at the sMAG
and currently referenced in the mobile node regular BCE before the
transient registration starts.
Transient proxy Care-of Address (t-pCoA):
The mobile node's proxy care-of address that is hosted at tMAG and
has been registered by the tMAG during a mobile node transient
registration procedure. It is the pCoA in an active tBCE.
3. PMIPv6 Transient Registration Overview
Several scenarios have been identified relevant to PMIPv6 support for
mobile nodes multihoming where a mobile node is multihomed through
different interfaces simultaneously accessing the same PMIPv6 domain.
Transient multihoming scenario has been described in [4] where a
mobile node is transitionally multihomed using different proxy
care-of addresses for a short period of time. This transient
multihoming scenario is enabled through PMIPv6 support of transient
registration.
During active inter-MAG handoff scenario, a transitional period of
time requires the LMA in the PMIPv6 domain to accept uplink traffic
for the same mobile node but through different MAGs. Context
transfer is assumed to provide the needed mobile node information and
parameters to enable the target MAG to send a proxy BU message with
the same HNP and interface ID, however, with an indication that the
current registration is a transient registration with a short
lifetime. As soon as the LMA receives a P-BU with transient
registration mobility option, the LMA identifies the mobile nodes
current pBCE which reflects the s-pCoA and creates a new tBCE with a
lifetime as specified in the TRO lifetime field. Additionally, the
LMA tags the tBCE as uplink traffic forwarding as per the traffic
direction in the TRO. Figure 1 shows a mobile node binding cache
entry state during inter-MAG active handoff using a single interface
to access the PMIPv6 domain.
Muhanna, et al. Expires August 28, 2008 [Page 5]
Internet-Draft PMIPv6 Support Transient Registration February 2008
Mobile node's BCE States @ LMA
==============================
Before tReg.
MN-if1 [prefix1 @ sMAG] [pBCE]
During tReg.
MN-if1 [prefix1 @ tMAG] [tBCE]
MN-if1 [prefix1 @ sMAG] [pBCE]
After tReg.
MN-if1 [prefix1 @ tMAG] [pBCE]
MN-if1 [prefix1 @ sMAG] [removed]
+=====+ if1 +------+ +------+
| MN |---------->| | | |
+=====+ | tMAG |\ +=================+ | |
| | | \ / \ | |
^ +------+ \ / IPv6/IPv4 Transport \ | L |
MN +---+ ...... +----| M |
Handover +------+ / \ IPv6/IPv4 Transport / | A |
^ | | / \ / | |
...^... if1 | sMAG |/ +=================+ | |
| MN |...........| | | |
....... +------+ +------+
|<------------------ PMIPv6 Domain ---------------->|
Figure 1: PMIPv6 Transient Multihoming during Inter-MAG handoff Over
one Interface.
It is assumed that during the active inter-MAG handoff and when the
tMAG sends a P-BU for a new transient BCE, the mobile node is homed
at the target MAG. However, in order to guarantee safe and on time
delivery of the uplink and downlink traffics, a transient BCE with
uplink traffic forwarding capability is necessary. During the tBCE
lifetime, the LMA continue to send all of the mobile node downlink
traffic to the sMAG. It is also assumed that the source MAG is aware
of the mobile node's current point of attachment and forward all of
the downlink traffic to the mobile node accordingly.
4. Transient Registration Option
Transient Registration Option, TRO, is included in the P-BU message
Muhanna, et al. Expires August 28, 2008 [Page 6]
Internet-Draft PMIPv6 Support Transient Registration February 2008
by the tMAG to indicate to the LMA that it is requesting the
registration and creation of a transient BCE with the criterias as
defined in the TRO. The source IP address of the P-BU is considered
the transient CoA while the lifetime field specifies the transient
BCE lifetime in one-tenth of seconds. The transient traffic field
specifies the traffic forwarding capability throughout the tBCE
lifetime, which in this case is limited to uplink only. The
Transient Registration option has an alignment requirement of 4n+2.
Its format is as shown in Figure 2 below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (R) | Trans. Traffic| Transient BCE Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Transient Registration Option Format
Type
<IANA>
Length
8-bit unsigned integer indicating the length in octets of this
option, excluding the type and length fields. The value of this
field must be set to 4.
Reserved (R)
This 8-bit field is unused for now. The value MUST be initialized
to 0 by the sender and MUST be ignored by the receiver.
Transient Traffic Direction
This 8-bit field is used as a bit-wise field to specify the
transient traffic direction. The following values are specified.
00000001 Uplink Traffic Forward Capability
All remaining Values are reserved.
Transient BCE Lifetime
This 16-bit field specify the requested lifetime for the transient
BCE in the number one-tenth of a second.
Muhanna, et al. Expires August 28, 2008 [Page 7]
Internet-Draft PMIPv6 Support Transient Registration February 2008
5. Mobile Access Gateway Operation
During the mobile node inter-MAG handoff process, the target MAG gets
the current mobile node BCE information through an out of scope
context transfer mechanism. It is assumed that the target MAG have
access to the mobile node ID, HNP, Interface ID. When the target MAG
receives the indication that the mobile node is moving from the
source MAG access network area to the target MAG area, the target MAG
sends a PBU on behalf of the mobile node. In this PBU, the target
MAG specifies the MN-ID, HNP, and the interface ID as per PMIPv6 base
protocol.
On the other hand, the target MAG sets the HI to 3 and includes the
transient registration option to indicate to the LMA that this
registration is a transient registration P-BU and the LMA needs to
create a tBCE. The tMAG sets the value of the transient lifetime to
a value that is dependent on the deployment and operator specific.
Additionally, the tMAG indicates that transient traffic forwarding
capability is uplink only by setting the transient traffic field to a
value 1.
After the target MAG receives an indication that the mobile node has
completed the inter-MAG handoff process and the data path is ready to
move the tunnel completely from the source MAG to the target MAG, the
target MAG SHOULD send a PBU to allow the local mobility anchor to
update the tBCE to a regular BCE and to switch the data bath
completely to be delivered through the target care-of address. In
this case, the tMAG sends a PBU with the MN-ID, Interface ID, MN-HNP
and at the same time sets the HI to 3. The tMAG does not include the
transient registration option as shown in Figure 3.
Muhanna, et al. Expires August 28, 2008 [Page 8]
Internet-Draft PMIPv6 Support Transient Registration February 2008
+-----+ +-----+ +-----+ +-----+
| MN | |s-MAG| |t-MAG| | LMA |
+-----+ +-----+ +-----+ +-----+
| | | bi-directional |
| |<<<<<<<<========================>>>>>>>>|
| | | pBCE
| | | [HNP1, s-pCOA, IF1]
Handoff Event | | |
| MN HO Event | |
| | HO Event Acquire |
| | MN pBCE[MN-ID, HNP1, IF1] |
LL Attach to | | |
tMAG AN | |-------P-BU (tReg.)------->|
| | | Create tBCE
| | | [HNP1, t-pCOA, IF1]
| | | pBCE HO Progress
| | |<------P-BA (tReg.)--------|
| | | |
| | bi-directional |
| |<<<<<<<<========================>>>>>>>>|
| | | |
| | | uplink only |
| | |>>>>>>=============>>>>>>>>|
| | | |
| | HO Complete |
| | |----- P-BU (NO tReg.) ---->|
| | | |
| | | Update tBCE to pBCE
| | | pBCE=[HNP1, t-pCOA, IF1]
| | |<--------- P-BA -----------|
| |` | |
| | |<<<<<<<<===========>>>>>>>>|
| | | |
| | | remove Source pBCE
| | | |
Figure 3: Target MAG Update MN tBCE during Inter-MAG Handover
In the event that the target MAG receives downlink traffic destined
to the mobile node from the LMA over the MAG-LMA tunnel, the tMAG
MUST deliver the downlink traffic to the mobile node. In this case,
the tMAG choose not to send a PBU to update the mobile node tBCE.
The tMAG may assume that the LMA has updated the mobile node tBCE to
regular BCE possibly after the LMA received a de-registration message
from the source MAG for the pBCE with care-of address s-pCoA.
Muhanna, et al. Expires August 28, 2008 [Page 9]
Internet-Draft PMIPv6 Support Transient Registration February 2008
6. Local Mobility Anchor Operation
When an uplink packet is received from the MN through the target MAG,
the LMA MUST verify if the source address of the packet matches the
transient pCoA. If the address matches, the LMA MUST consider the
packet to be valid and MUST forward the packet appropriately based on
the contents of the decapsulated packet. If the mobile node's tBCE
indicates uplink traffic forwarding capability, the LMA MUST NOT use
the tBCE for sending out downlink traffic to the MN through the
target MAG.
When the LMA receives a PBU with the transient registration option
included and the MN-ID, HNP, and the IF-ID, the LMA allocates all the
binding cache entries for the same MN-ID. The LMA then identifies
the BCE that have the same HNP and Interface ID. The LMA set an
indication flag to "handoff in progress". The LMA creates a tBCE
after allocating the same HNP and sets the transient lifetime field
to the value received in the TRO. LMA sends a PBA with HI equals to
the value received in PBU and as per the processes in PMIPv6 base
protocol.
After the LMA creates the mobile node transient BCE, the LMA add
another routing entry to the MN for the new t-pCOA. As long as the
tBCE is active, the LMA MUST forward all of the mobile node
intercepted downlink traffic to the source pCOA.
7. Transient Binding Cache Entries Update
The transient binding cache entry, which was created by the procedure
described in this document, needs to be short lived. i.e. for the
duration of the inter-MAG handover. After the handover completes,
this entry needs to be updated to a pBCE state. At the same time,
the LMA deletes the mobile node pBCE which is tagged as "handoff in
progress" and points to the source pCOA which is hosted at the sMAG.
There are three ways by which this process can happen:
1. The target MAG sends a new PBU with HI value 3 (Handoff between
mobile access gateways for the same interface): The transient
binding cache entry is converted into a full blown binding cache
entry and the BCE for the source MAG is removed. Figure 3 shows
the call flow for this procedure.
Muhanna, et al. Expires August 28, 2008 [Page 10]
Internet-Draft PMIPv6 Support Transient Registration February 2008
2. The source MAG sends a deregistration PBU: The transient binding
cache entry is converted into a pBCE and the pBCE for the source
MAG is removed. Figure 4 shows the call flow for this procedure.
3. Transient BCE lifetime expires: If the tBCE lifetime expires
before the tBCE has been updated based on one of the above cases
Paragraph 1 or Paragraph 2, the LMA MUST update the tBCE to pBCE
and remove the pBCE for the source MAG as shown in Figure 5 .
Additionally, the LMA MAY send a revocation indication message to
indicate to the source MAG that the mobile node's pBCE has been
removed and it needs to clean associated resources.
Muhanna, et al. Expires August 28, 2008 [Page 11]
Internet-Draft PMIPv6 Support Transient Registration February 2008
+-----+ +-----+ +-----+ +-----+
| MN | |s-MAG| |t-MAG| | LMA |
+-----+ +-----+ +-----+ +-----+
| | | bi-directional |
| |<<<<<<<<========================>>>>>>>>|
| | | pBCE
| | | [HNP1, s-pCOA, IF1]
Handoff Event | | |
| MN HO Event | |
| | HO Event Acquire |
| | MN pBCE[MN-ID, HNP1, IF1] |
LL Attach to | | |
tMAG AN | | |
| | |-------P-BU (tReg.)------->|
| | | |
| | | Create tBCE
| | | [HNP1, t-pCOA, IF1]
| | | pBCE HO Progress
| | |<------P-BA (tReg.)--------|
| | | |
| | bi-directional |
| |<<<<<<<<========================>>>>>>>>|
| | | |
| | | uplink only |
| | |>>>>>>=============>>>>>>>>|
| HO | |
| Complete | |
| |------------- P-BU (de-Reg.) ---------->|
| | | |
| | | Remove Source pBCE
| |<------------------ P-BA ---------------|
| | | |
| | | Update tBCE to pBCE
| | | pBCE=[HNP1, t-pCOA, IF1]
| |` | |
| | |<<<<<<<<===========>>>>>>>>|
| | | |
Figure 4: Source MAG Deregister MN Old pBCE during Inter-MAG Handover
Muhanna, et al. Expires August 28, 2008 [Page 12]
Internet-Draft PMIPv6 Support Transient Registration February 2008
+-----+ +-----+ +-----+ +-----+
| MN | |s-MAG| |t-MAG| | LMA |
+-----+ +-----+ +-----+ +-----+
| | | |
| | | tBCE Active
| | | tReg. Lifetime Start
| | bi-directional |
| |<<<<<<<<========================>>>>>>>>|
| | | |
| | | uplink only |
| | |>>>>>>=============>>>>>>>>|
| HO | |
| Complete | |
| | | tReg. Lifetime Expires
| | | No PBU from tMAG
| | | No De-reg. from sMAG
| | | |
| | | |
| | | Update tBCE to pBCE
| | | bi-directional |
| | |<<<<<<<<===========>>>>>>>>|
| | | |
| | | remove source pBCE
| | | |
| | | |
Figure 5: LMA Updates Transient BCE upon Transient Registration
Lifetime Expiry
8. IANA Considerations
This document defines one new Mobility Header option, the Transient
Registration option, which is described in Figure 2. The Type value
for this option needs to be assigned from the same numbering space as
allocated for the other mobility options, as defined in [3].
9. Security Considerations
This document does not present any new security requirement on the
top of the security requirements listed in PMIPv6 base protocol [1].
It only presents a mechanism which allows a mobile node to be
transitionally multihomed at two care of addresses during an inter-
MAG active handoff using the existing trust relationship and security
Muhanna, et al. Expires August 28, 2008 [Page 13]
Internet-Draft PMIPv6 Support Transient Registration February 2008
association between the LMA and the source and target MAGs.
10. Acknowledgements
The idea to capture transient registration as presented in this
document came out of a discussion during IETF70 at Vancouver in
December 2007. The following people were involved in the discussion
(listed by last name) Kuntal Chowdhury, Vijay Devarapalli, Sri
Gundavelli, Lalit Kotecha, Suresh Krishnan, Kent Leung and Ahmad
Muhanna.
11. References
11.1. Normative References
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-11
(work in progress), February 2008.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Muhanna, A. and M. Khalil, "Proxy MIPv6 support for Mobile Nodes
with Multihoming", draft-muhanna-netlmm-multihoming-support-01
(work in progress), February 2008.
11.2. Informative References
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[6] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile
IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in
progress), November 2007.
Muhanna, et al. Expires August 28, 2008 [Page 14]
Internet-Draft PMIPv6 Support Transient Registration February 2008
Authors' Addresses
Ahmad Muhanna
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Phone: +1 (972) 685-1416
Email: amuhanna@nortel.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 (514) 345-7900 x42871
Email: suresh.krishnan@ericsson.com
Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: kleung@cisco.com
Basavaraj Patil
Nokia Siemens Networks
6000 Connection Drive
Irving, TX 75039
USA
Email: basavaraj.patil@nsn.com
Muhanna, et al. Expires August 28, 2008 [Page 15]
Internet-Draft PMIPv6 Support Transient Registration 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).
Muhanna, et al. Expires August 28, 2008 [Page 16]