|
Dear,
We just posted a new I-D:
draft-li-ccamp-multinodes-gr-proc-00.txt for which your comments are very
welcome! The following is the abstract of this new I-D, please check out the
attachment for details.
This document only clarifies the control plane
procedures for a GMPLS network when there are multiple node failures, and
describes how full control plane state can be recovered depending on the order
in which the nodes restart. We know there still have some issues which we
have not awared of, so we strongly encourage you to send your comments to this
mailing list.
Abstract
The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. GMPLS protocol definitions for RSVP also allow a restarting node to learn the label that it previously allocated for use on a Label Switching Path (LSP). Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors. This document clarifies the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered depending on the order in which the nodes restart. Best regards,
Dan Li
|
Network Working Group Dan Li
Internet Draft Jianhua Gao
Huawei
Proposed Status: Informational
Expires: December 2006 June, 2006
Procedure for Multiple Node Graceful Restart
draft-li-ccamp-multinodes-gr-proc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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
Abstract
The Hello message for the Resource Reservation Protocol (RSVP) has
been defined to establish and maintain basic signaling node
adjacencies for Label Switching Routers (LSRs) participating in a
Multiprotocol Label Switching (MPLS) traffic engineered (TE) network.
The Hello message has been extended for use in Generalized MPLS
(GMPLS) network for state recovery of control channel or nodal faults.
Li Expires December 2006 [Page 1]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
GMPLS protocol definitions for RSVP also allow a restarting node to
learn the label that it previously allocated for use on a Label
Switching Path (LSP).
Further RSVP protocol extensions have been defined to enable a
restarting node to recover full control plane state by exchanging
RSVP messages with its upstream and downstream neighbors.
This document clarifies the control plane procedures for a GMPLS
network when there are multiple node failures, and describes how full
control plane state can be recovered depending on the order in which
the nodes restart.
Conventions used in this document
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].
Table of Contents
1. Introduction................................................3
2. Existing Procedures.........................................4
2.1. Procedures defined in [RFC3473].........................4
2.2. Procedures defined in [GR-EXT]..........................4
3. Multiple Node Restart Scenarios..............................5
4. RSVP state..................................................6
5. Procedures..................................................7
5.1. Procedures for the Normal Node..........................7
5.2. Procedures for the Restarting Node......................7
5.2.1. Procedures for Scenario 1..........................7
5.2.2. Procedures for Scenario 2..........................8
5.2.3. Procedures for scenario 3.........................10
5.2.4. Procedures for scenario 4.........................11
5.2.5. Procedures for scenario 5.........................11
5.3. Consideration of Re-Use of Data Plane Resources.........11
5.4. Consideration of Management Plane Intervention..........12
6. Security Considerations.....................................12
7. IANA Considerations........................................12
8. Acknowledgments............................................12
9. References.................................................12
9.1. Normative References...................................12
10. Author's Addresses........................................13
11. Full Copyright Statement...................................13
Li Expires December 2006 [Page 2]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
12. Intellectual Property Statement............................14
1. Introduction
The Hello message for the Resource Reservation Protocol (RSVP) has
been defined to establish and maintain basic signaling node
adjacencies for Label Switching Routers (LSRs) participating in a
Multiprotocol Label Switching (MPLS) traffic engineered (TE) network
[RFC3209]. The Hello message has been extended for use in Generalized
MPLS (GMPLS) network for state recovery of control channel or nodal
faults through the exchange of the Restart Capabilities object
[RFC3473].
GMPLS protocol definitions for RSVP [RFC3473] also allow a restarting
node to learn the label that it previously allocated for use on a
Label Switching Path (LSP) through the Recovery Label object carried
on a Path message sent to a restarting node from its upstream
neighbor.
Further RSVP protocol extensions have been defined [GR-EXT] to
perform graceful restart and to enable a restarting node to recover
full control plane state by exchanging RSVP messages with its
upstream and downstream neighbors. State previously transmitted to
the upstream neighbor (principally the downstream label) is recovered
from the upstream neighbor on a Path message (using the Recovery
Label object as described in [RFC3473]). State previously transmitted
to the downstream neighbor (including the upstream label, interface
identifiers, and the explicit route) is recovered from the downstream
neighbor using a RecoveryPath message.
[GR-EXT] also extends the Hello message to exchange information about
the ability to support the RecoveryPath message.
The examples and procedures in [GR-EXT] focus on the description of a
single node restart when adjacent network nodes are operative.
Although the procedures are equally applicable to multi-node restarts,
no detailed explanation is provided.
This document clarifies the control plane procedures for a GMPLS
network when there are multiple node failures, and describes how full
control plane state can be recovered depending on the order in which
the nodes restart.
Li Expires December 2006 [Page 3]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
2. Existing Procedures
2.1. Procedures defined in [RFC3473]
In the case of nodal faults, the procedures for the restarting node
and the procedures for the neighbor of a restarting node are applied
to the corresponding nodes. These procedures described in [RFC3473]
are summarized as follows:
For the Restarting Node:
1. Tells its neighbours that state recovery is supported using the
Hello message;
2. Recovers its RSVP state with the help of a Path message received
from its upstream neighbor carrying the Recovery_Label Object;
3. For bidirectional LSPs, the Upstream_Label Object on the received
Path message is used to recover the corresponding RSVP state;
For the Neighbor of a restarting node:
1. Sends the Path message with Recovery_Label Object containing a
label value corresponding to the label value received in the most
recently received corresponding Resv message;
2. Resumes refreshing Path state with the restarting node;
3. Resumes refreshing Resv state with the restarting node.
2.2. Procedures defined in [GR-EXT]
A new message is introduced in [GR-EXT] which is called the
RecoveryPath message. The message is sent by the downstream neighbor
of a restarting node to convey the contents of the last received Path
message back to the restarting node.
The restarting node will receive the Path message with the Recovery
Label object from its upstream neighbor, and/or the RecoveryPath
message from its downstream neighbor. The full RSVP state of the
restarting node can be recovered from these two messages.
From the received Path message the following state can be recovered:
o Upstream data interface (from RSVP HOP)
o Label on the upstream data interface (from Recovery Label Object)
Li Expires December 2006 [Page 4]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
o Upstream label for bidirectional LSP (from Upstream Label Object)
From the received RecoveryPath message the following state can be
recovered:
o Downstream data interface (from RSVP HOP)
o Label on the downstream data interface (from Recovery Label Object)
o Upstream direction label for bidirectional LSP (from Upstream
Label Object)
The other objects also can be recovered either by regular Path
message or RecoveryPath message, and Resv message.
3. Multiple Node Restart Scenarios
We define the following terms for the different node types:
Restarting - The node has restarted; communication with its neighbor
nodes is restored, its RSVP state is under recovery.
Delayed Restarting - The node has restarted, but the communication
with a neighbor node is interrupted (for example, the neighbor node
needs to restart).
Normal - The normal node is the neighbor of a restarting or delayed
restarting node.
There are five scenarios for multi-node restart. We will focus on the
different positions of a restarting node. As shown in Figure 1, an
LSP starts from Node A, traverses Nodes B and C, and stops at Node D.
+-----+ Path +-----+ Path +-----+ Path +-----+
| PSB |------->| PSB |------->| PSB |------->| PSB |
| | | | | | | |
| RSB |<-------| RSB |<-------| RSB |<-------| RSB |
+-----+ Resv +-----+ Resv +-----+ Resv +-----+
Node A Node B Node C Node D
Figure 1 Two neighbor nodes restart
1. A Restarting node with downstream Delayed Restarting node. For
example, as shown in Figure 1, Nodes A and D are Normal nodes,
Node B is a Restarting node, and Node C is a Delayed Restarting
node.
Li Expires December 2006 [Page 5]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
2. A Restarting node with upstream Delayed Restarting node. For
example, as shown in Figure 1, Nodes A and D are Normal nodes,
Node B is a Delayed Restarting node, and Node C is a Restarting
node.
3. A Restarting node with downstream and upstream Delayed Restarting
nodes. For example, as shown in Figure 1, Node A is a Normal node,
Nodes B and D are Delayed Restarting nodes, and Node C is a
Restarting node.
4. A restarting Ingress node with downstream Delayed Restarting node.
For example, as shown in Figure 1, Node A is a Restarting node,
and Node B is a Delayed Restarting node. Nodes C and D are Normal
nodes.
5. A restarting Egress node with upstream Delayed Restarting node.
For example, as shown in Figure 1, Nodes A and B are Normal nodes,
Node C is a Delayed Restarting node, and Node D is a Restarting
node.
If the communication between two nodes is interrupted, the upstream
node may think the downstream node is a Delayed Restarting node, or
vice versa.
4. RSVP state
For each scenario, the RSVP state needs to be recovered at the
restarting nodes are Path State Block (PSB) and Resv State Block
(RSB), which are created when the node receives the corresponding
Path message and Resv message.
According to [RFC2209], how to construct the PSB and RSB is really an
implementation issue. In fact, there is no requirement to maintain
separate PSB and RSB data structures. And in GMPLS, there is a much
closer tie between Path and Resv state so it is possible to combine
the information into a single state block (the LSP state block). On
the other hand, if P2MP is supported, it may be convenient to
maintain separate upstream and downstream state. Note that the PSB
and RSB are not upstream and downstream state since the PSB is
responsible for receiving a Path from upstream and sending a Path to
downstream.
Regardless of how the RSVP state is implemented, on recovery there
are two logical pieces of state to be recovered, and these correspond
to the PSB and RSB.
Li Expires December 2006 [Page 6]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
5. Procedures
In this document, all the nodes are assumed to have the graceful
restart capabilities which are described in [RFC3473] and [GR-EXT].
5.1. Procedures for the Normal Node
When the downstream Normal node detects its neighbor restarting, it
MUST send a RecoveryPath message for each LSP associated with the
restarting node for which it has previously sent a Resv message and
which has not been torn down.
When the upstream Normal node detects its neighbor restarting, it
MUST send a Path message with Recovery_Label Object containing a
label value corresponding to the label value received in the most
recently received corresponding Resv message.
This document does not modify the procedures for the Normal node
which are described in [RFC3473] and [GR-EXT].
5.2. Procedures for the Restarting Node
5.2.1. Procedures for Scenario 1
After the Restarting node restarts, set a Recovery Timer. Any RSVP
state that cannot be resynchronized before the Recovery Timer expires
SHOULD be cleared.
At the Restarting node (Node B), full resynchronization with the
upstream neighbor (Node A) is possible because Node A is a Normal
node. The upstream Path information is recovered from the Path
message received from Node A. Node B also recovers the upstream Resv
information from the Recovery_Label object carried in the Path
message received from Node A, but, obviously, some information (like
the Recorded Route Object) will be missing from the Resv message, and
can not be supplied until the downstream Delayed Restarting node
(Node C) restarts and sends a Resv.
As per [GR-EXT], the Restarting node (Node B) would normally expect
to receive a RecoveryPath message from its downstream neighbor (Node
C). It would use this to recover the downstream Path and Resv
information. But in this scenario, because the downstream neighbor
has not restarted yet, Node B detects the communication with Node C
is interrupted and must wait before resynchronizing with its
downstream neighbor.
Li Expires December 2006 [Page 7]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
In this case, the Restarting node (Node B) follows the procedures in
section 9.3 of [RFC3473] and MAY run a Restart Timer to wait for the
downstream neighbor (Node C) to restart. If its downstream neighbor
(Node C) has not restarted before the timer expires the corresponding
LSPs MAY be torn down according to local policy [RFC3473]. Note,
however, that the Restart Time value suggested in [RFC3473] is based
on the previous Hello message exchanged with the node that has not
restarted yet (Node C). Since this time value is unlikely to be
available to the restarting node (Node B), a configured time value
MUST be used if the timer is operated.
The RSVP state MUST be reconciled with the retained data plane state
if the cross-connect information can be retrieved from the data plane.
In the event of any mismatches, local policy will dictate the action
that must be taken which could include:
- reprogramming the data plane
- sending an alert to the management plane
- tearing down the control plane state for the LSP.
In the case that the Delayed Restarting node never comes back, and
where a Restart Timer is not used to automatically tear down LSPs,
the LSPs can be tidied up through the control plane using a PathTear
from the upstream node (Node A). Note that if Node C restarts after
this operation, the RecoveryPath message that it sends to Node B will
not be matched with any state on Node B and will receive a PathTear
as its response resulting in the teardown of the LSP at all
downstream nodes.
5.2.2. Procedures for Scenario 2
In this case, the Restarting node (Node C) can recover full
downstream state from its downstream neighbor (Node D) which is a
Normal node. The downstream Path state can be recovered from the
RecoveryPath message which is sent by Node D. This allows Node C to
send a Path refresh message to Node D, and Node D will respond with a
Resv message from which Node C can reconstruct the downstream Resv
state.
Li Expires December 2006 [Page 8]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
The Restarting node would normally expect to resynchronize with its
upstream neighbor to re-learn the upstream Path and Resv state, but
in this scenario, because the upstream neighbour (Node B) has not
restarted yet, the Restarting node (Node C) detects that the
communication with upstream neighbor (Node B) is interrupted. The
Restarting node (Node C) follows the procedures in section 9.3 of
[RFC3473] and MAY run a Restart Timer to wait the upstream neighbor
(Node B) to restart. If its upstream neighbor (Node B) has not
restarted before the Restart Timer expires, the corresponding LSPs
MAY be torn down according to local policy [RFC3473]. Note, however,
that the Restart Time value suggested in [RFC3473] is based on the
previous Hello message exchanged with the node that has not restarted
yet (Node B). Since this time value is unlikely to be available to
the restarting node (Node C), a configured time value MUST be used if
the timer is operated.
Note that no Resv message is sent to the upstream neighbor (Node B)
because it has not restarted.
The RSVP state MUST reconcile with the retained data plane state if
the cross-connect information can be retrieved from the data plane.
In the event of any mismatches, local policy will dictate the action
that must be taken which could include:
- reprogramming the data plane
- sending an alert to the management plane
- tearing down the control plane state for the LSP.
In the case that the Delayed Restarting node never comes back, and
where a Restart Timer is not used to automatically tear down LSPs,
the LSPs cannot be tidied up through the control plane using a
PathTear from the upstream node (Node A) because there is no control
plane connectivity to Node C from the upstream direction. There are
two possibilities in [RFC3473]:
- Management action may be taken at the Restarting node to tear the
LSP. This will result in the LSP being removed from Node C, and a
PathTear being sent downstream to Node D.
- Management action may be taken at any downstream node (for example,
Node D) resulting in a PathErr message with the Path_State_Reomved
flag set being sent to Node C to tear the LSP state.
Li Expires December 2006 [Page 9]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
Note that if Node B restarts after this operation, the Path message
that it sends to Node C will not be matched with any state on Node C
and will be treated as a new Path message resulting in LSP setup.
Node C SHOULD use the labels carried in the Path message (in the
Upstream_Label object and in the Recovery_Label object) to drive its
label allocation, but MAY use other labels according to normal LSP
setup rules.
5.2.3. Procedures for scenario 3
In this example, the Restarting node (Node C) is isolated. It's
upstream and downstream neighbors have not restarted.
The Restarting node (Node C) follows the procedures in section 9.3 of
[RFC3473] and MAY run a Restart Timer for each of its neighbors
(Nodes B and D). If a neighbor has not restarted before its Restart
Timer expires, the corresponding LSPs MAY be torn down according to
local policy [RFC3473]. Note, however, that the Restart Time values
suggested in [RFC3473] are based on the previous Hello message
exchanged with the nodes that have not restarted yet. Since these
time values are unlikely to be available to the restarting node (Node
C), a configured time value MUST be used if the timer is operated.
During the Recovery Time, if the upstream Delayed Restarting node has
restarted, the procedure for scenario 1 can be applied.
During the Recovery Time, if the downstream Delayed Restarting node
has restarted, the procedure for scenario 2 can be applied.
In the case that neither Delayed Restarting node ever comes back, and
where a Restart Timer is not used to automatically tear down LSPs,
management intervention is required to tidy up the control plane and
the data plane on the nodes that are waiting for the failed device to
restart.
If the downstream Delayed Restarting node restarts after the cleanup
of LSPs at Node C, the RecoveryPath message from Node D will be
responded with a PathTear message. If the upstream Delayed Restarting
node restarts after the cleanup of LSPs at Node C, the Path message
from Node B will be treated as a new LSP setup request, but the setup
will fail because Node D cannot be reached - Node C will respond with
a PathErr message. Since this happens to Node B during its restart
processing, it SHOULD follow the rules of [GR-EXT] and tear the LSP
down.
Li Expires December 2006 [Page 10]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
5.2.4. Procedures for scenario 4
When the Ingress node (Node A) restarts, it does not know which LSPs
it caused to be created. Usually, however, this information is
retrieved from the management plane or from the configuration
requests stored in non-volatile form in the node the in order to
recover the LSP state.
Further, if the downstream node (Node B) has is a Normal node,
according to [GR-EXT] that the ingress will receive a RecoveryPath
message and will understand that it was the ingress of the LSP.
However, in this scenario, the downstream node is a Delayed
Restarting node, so node A must rely on the information from the
management plane or stored configuration, or it must wait for node B
to restart.
In the event that node B never restarts, management plane
intervention may be used at node A to clean up any LSP state restored
from the management plane or from local configuration.
5.2.5. Procedures for scenario 5
In this scenario the Egress node (Node D) restarts, and its upstream
neighbor (Node C) has not restarted. In this case, the Egress node is
completely unaware of the LSPs. It has no downstream neighbor to help
it, and no management plane or configuration information. The Egress
node must simply wait until its upstream neighbor restarts and gives
it the information as Path messages carrying Recovery_Label objects.
5.3. Consideration of Re-Use of Data Plane Resources
Fundamental to the processes described above is an understanding that
data plane resources may remain in use (allocated and cross-connected)
when control plane state has not been fully resynchronized because
some control plane nodes have not restarted.
It is assumed that these data plane resources might be carrying
traffic and SHOULD NOT be reconfigured except through application of
operator-configured policy, or as a direct result of operator action.
In particular, new LSP setup requests from the control plane or the
management plane SHOULD NOT be allowed to use data plane resources
that are still in use. Specific action MUST first be taken to release
the use of resources.
Li Expires December 2006 [Page 11]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
5.4. Consideration of Management Plane Intervention
The management plane MUST always retain the ability to control data
plane resources and to over-ride the control plane. In this context,
the management plane MUST always be able to release data plane
resources that were previously in place for use by control-plane
established LSPs. Further, the management plane MUST always be able
to instruct any control plane node to tear down any LSP.
Operators should be aware of the risks of misconnection that could be
caused by careless manipulation from the management plane of in-use
data plane resources.
6. Security Considerations
This document clarifies the procedures to be performed on RSVP agents
that neighbor one or more restarting RSVP agents. In the case of the
control plane in general, and the RSVP agent in particular, where one
or more nodes carrying one or more LSPs are restarted due to external
attacks, the procedures described in this document provide the
ability for the restarting RSVP agents to recover the RSVP state in
each restarting node corresponding to the LSPs, with the least
possible perturbation to the rest of the network. Ideally, only the
neighboring RSVP agents should notice the restart and hence need to
perform additional processing. This allows for a network with active
LSPs to recover LSP state gracefully from an external attack, without
perturbing the data/forwarding plane state.
7. IANA Considerations
This document defines no new protocols or extensions and makes no
requests to IANA for registry management.
8. Acknowledgments
We would like to thank Adrian Farrel for his useful comments.
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.
[RFC2209] R. Braden, L. Zhang, "Resource ReSerVation Protocol (RSVP)
-- Version 1 Message Processing Rules", RFC 2209,
September 1997.
Li Expires December 2006 [Page 12]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[GR-EXT] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP
Graceful Restart", Internet Draft, work in progress,
draft-ietf-ccamp-rsvp-restart-ext-05.txt, October 2005
10. Author's Addresses
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972910
Email: danli@huawei.com
Jianhua Gao
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972902
Email: gjhhit@huawei.com
11. Full 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.
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.
Li Expires December 2006 [Page 13]
Internet-Draft draft-li-ccamp-multinodes-gr-proc-00.txt June 2006
12. 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.
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".
Li Expires December 2006 [Page 14]