Networking Working Group M. Kim, Ed.
Internet-Draft KT
Intended status: Standards Track JP. Vasseur, Ed.
Expires: April 19, 2009 Cisco Systems
H. Chong
KT
October 16, 2008
Routing Metrics used for Path Calculation in Low Power and Lossy
Networks
draft-mjkim-roll-routing-metrics-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 April 19, 2009.
Abstract
This document specifies routing metrics to be used in path
calculation for Routing Over Low power and Lossy networks (ROLL).
Low power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired networks or even with similar ones
such as mobile ad-hoc networks. By contrast with typical Interior
Gateway Protocol (IGP) routing metrics using hop counts or link
metrics, this document specifies a set of routing metrics suitable to
LLNs.
Kim, Vasseur et al. Expires April 19, 2009 [Page 1]
Internet-Draft Routing Metrics for LLNs October 2008
Table of Contents
1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Node attributes . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Node resources . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Residual Energy . . . . . . . . . . . . . . . . . . . . . 6
4.3. Node workload . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Node latency . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Data Aggregation attribute . . . . . . . . . . . . . . . . 7
4.6. Node degree . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Dynamicity . . . . . . . . . . . . . . . . . . . . . . . . 8
4.8. Node reliability . . . . . . . . . . . . . . . . . . . . . 8
5. Link metrics and attributes . . . . . . . . . . . . . . . . . 9
5.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Reliability (Quality) . . . . . . . . . . . . . . . . . . 9
5.3. Propagation delay . . . . . . . . . . . . . . . . . . . . 10
5.4. Bi-directionality . . . . . . . . . . . . . . . . . . . . 10
5.5. Link Coloring . . . . . . . . . . . . . . . . . . . . . . 10
6. Computation of dynamic metrics and attributes . . . . . . . . 10
7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Metric consistency . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Kim, Vasseur et al. Expires April 19, 2009 [Page 2]
Internet-Draft Routing Metrics for LLNs October 2008
1. Note
Some of the routing metrics defined in this document may be subject
to change or may even be removed in light of the routing requirements
currently being specified by the Routing Over Low power and Lossy
networks (ROLL) Working Group. For the sake of illustration, some
metrics are only meaningful in routing protocols that fall into the
category of Distance Vector. Since the Working Group has not yet
determined which routing protocol will be chosen for Low power and
Lossy Networks (LLNs), it is not yet possible to determine whether
such metrics will be required. Conversely, other metrics may be
further specified depending on which routing protocol is selected by
the Working Group.
In this revision of the document, a list of link and node metrics is
specified. It is well understood that some of these metrics are by
nature highly dynamic, which may lead to routing oscillations.
Furthermore, dynamic metrics may be too CPU intensive for highly
constrained devices. Consequently, it is probable that some of them
will be removed from this document in light of the discussion that
will take place in the Working Group.
Link and node metrics packet format or methods to encode the data
will be defined in a further revision of this document.
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].
This document makes use of the terminology defined in [I-D.ietf-
terminology].
o Mobile LLN: Low power and Lossy Network where some nodes are
mobile.
o Fixed LLN: Low power and Lossy Network where all nodes are static,
not mobile.
3. Introduction
This document specifies routing metrics to be used in path
calculation for Routing Over Low power and Lossy networks (ROLL).
Low power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired networks or even with similar ones
Kim, Vasseur et al. Expires April 19, 2009 [Page 3]
Internet-Draft Routing Metrics for LLNs October 2008
such as mobile ad-hoc networks. By contrast with typical Interior
Gateway Protocol (IGP) routing metrics using hop counts or link
metrics, this document specifies a set of routing metrics suitable to
LLNs.
Routing metrics can be classified according to the following set of
characteristics:
- Link versus Node metrics
- Qualitative versus quantitative
- Dynamic or static
Historically, IGP such as OSPF [RFC2328] and IS-IS [RFC1142] have
been using quantitative static link metrics. Other mechanisms such
as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
[RFC2702] make use of other link attributes such as the available
reserved bandwidth, affinities and so on to compute constrained
shortest paths for Traffic Engineering Label Switched Paths (TE
LSPs).
It must be noted that the use of dynamic metrics is not new and has
been experimented in ARPANET 2 [Khanna1989], with a moderate success.
Indeed, the use of dynamic metrics is not trivial and very careful
care must be given to the use of dynamic metrics that may lead to
potential routing instabilities.
As pointed out in various routing requirements documents (see
draft-ietf-roll-urban-routing-reqs,
draft-ietf-roll-indus-routing-reqs,
draft-ietf-roll-home-routing-reqs) in LLNs, it is required to take
into account a set of node constraints during path computation. Node
metrics include node's resources such as memory, energy and CPU
(computational power). Moreover, node attributes such as the ability
to act as an aggregator (node capable of performing data aggregation)
may be of interest. Additionally, work load, transmission range and
dynamicity (mobility, duty cycle, etc) may also be considered. Link
attributes include propagation delay, reliability (quality) and
available bandwidth.
By contrast with the current Internet, links and nodes in LLNs have
changing characteristics in terms of reliability and available
resources. Thus, it is required to specify a set of dynamic metrics.
For instance, even though a wireless sensor network topology is
static in absence of failure, nodes' workload and resource such as
residual energy and available memory are changing continuously and
may have to be taken into account during the path computation.
Kim, Vasseur et al. Expires April 19, 2009 [Page 4]
Internet-Draft Routing Metrics for LLNs October 2008
Similarly, link attributes including latency and reliability may
change over time because moving obstacles can appear at any time.
That being said, very careful attention must be given when using
highly dynamic metrics and attributes that affect routing decisions
in order to preserve the routing stability. Furthermore, it is time
and energy consuming process to update these dynamic metrics and
recompute the routing tables on a frequent basis. Therefore, it may
be desirable to use a set of discrete values to reduce computational
overhead and bandwidth utilization. Of course, this comes with a
cost, namely, reduced metric accuracy.
Reliability is an example of qualitative parameter. However, to be
routing metrics for path calculation, qualitative parameters may be
transformed to quantitative values. Rules must be defined to make
the qualitative parameters appear in quantitative forms.
Quantitative form can be numbers or levels.
This document specifies a set of link and nodes metrics that can be
used to compute paths within a LLN. Some link or node attributes
(e.g. level of link reliability, energy remaining on the node) can be
used to perform constraint-based routing. It is not required to use
all the metrics and attributes specified in this document. A
particular implementation MAY use a subset or all of the metrics
defined in this document.
The specification of the objective function used to compute the path
is out of the scope of this document.
4. Node attributes
In most cases, node attributes are static. However, critical
attributes such as residual power might need to be considered as
dynamic attributes and monitored continuously in some scenarios. An
implementation MUST make use of multi-threshold scheme rather than
fine granular metric update so as to avoid constant routing changes.
"Multi-threshold scheme" sets a few levels to categorize metric
values and uses the levels as discrete values instead of actual
values.
In LLNs, it is not uncommon to have highly heterogeneous nodes in
term of capabilities (e.g. node being battery operated or not, amount
of memory, etc) and functionalities. More capable and stable nodes
can assist the most constrained ones for routing packets, which
results in extension of network lifetime and efficient network
operations. This implies that constraint-based routing will be used
in some cases. Thus, the computed path may not be the shortest path
according to some specified metrics.
Kim, Vasseur et al. Expires April 19, 2009 [Page 5]
Internet-Draft Routing Metrics for LLNs October 2008
4.1. Node resources
Memory and CPU resources are critical node resources in presence of
constrained nodes. Resource-awareness should be employed to routing
protocols strictly or loosely considering trade-off between cost and
benefit.
4.2. Residual Energy
Low power is one of the most distinguished features of LLNs, so node
residual energy is a pivotal metric in environments where nodes are
battery powered. Residual energy should be taken as a relative value
considering statistical node lifetime and other conditions such as
the role of the node in the network. For example, if the node's
expected lifetime is 5 years and the remaining energy is only one
fifth, then the energy is a critical resource for the node. In such
cases, the routing protocol engine may compute a longer path
(constrained based) for some traffic in order to increase the network
life duration. Hence, whenever possible, the node should not be
selected as a router (an intermediate node to deliver data), thus the
support for constrained-based routing is needed. Another typical use
of constrained-based routing consists of using a node attribute as a
routing criterion. For example, the routing engine may prefer a
"longer" path that traverses main powered nodes or nodes equipped
with rechargeable batteries. Algorithm can be designed to consider a
combination of node metrics and node attributes. Algorithms defining
how such metrics and attributes should be combined are outside of the
scope of this document.
Generally, the residual energy should be taken as a dynamic metric.
Most battery operated devices have the ability to estimate the
remaining energy [I-D.ietf-roll-indus-routing-reqs]. However,
initial energy status can be considered as a static metric in some
situations where monitoring the energy level is too CPU intensive.
Simply categorizing devices into two classes, main-powered and
battery-powered may be sufficient to compute the path in highly
constrained scenarios.
4.3. Node workload
Node workload may be hard to determine and express in some scalar
form. However, node workload could be a useful metric to consider
during path calculation, in particular when data processing along the
data path is required or queuing delays must be minimized for highly
sensitive traffic. Using a simple 1-bit flag to characterize the
node workload may provide a sufficient level of granularity,
similarly to the "overload" bit used in protocols such as IS-IS
[RFC1142]. An implementation may then decide to exclude from its
Kim, Vasseur et al. Expires April 19, 2009 [Page 6]
Internet-Draft Routing Metrics for LLNs October 2008
routes any node with a "heavy" value for workload unless there is no
alternative.
4.4. Node latency
Node latency is defined as the time span from the arrival time to the
departure time of a given packet at a node. It is primarily made up
of packet processing time, queuing delays and packet transmission
time. Node latency is highly correlated with other metrics. Indeed,
heavy workload increases node latency.
4.5. Data Aggregation attribute
Some nodes may sense or receive the same (or similar) data if the
nodes are located in a close area due to data correlation. Thus,
data aggregation/fusion may be possible. Data fusion involves more
complicated processing to improve accuracy of the output data while
data aggregation mostly aims to reduce the amount of data.
Especially in urban applications where sensor nodes collect
environmental information and send it to a data sink, a potentially
large amount of nodes sense similar data. For the sake of
illustration, consider the simple example shown in the Figure 1. Let
us assume that three nodes A, B and C need to send sensed data to the
data sink. Node A sensed "xyz" and sent this data to node C. Since C
also sensed same data, it has no additional information from node A.
However, because the data node B sent is "xqz", node C aggregates
this data with its own data "xyz" resulting in "xyqz". Therefore,
node C sends "xyqz" to the data sink. In this example, each node's
data requires 3 bytes. If no aggregation is performed, node C needs
to send 9 byte data to the sink, but C only sends 4 bytes thanks to
data aggregation.
A B
|------| |------|
| xyz | | xqz |
|______| |______|
\ /
\ /
\ C / sink
|------| xyqz |------|
| xyz |-----------| |
|______| |______|
Figure 1: Data aggregation
Kim, Vasseur et al. Expires April 19, 2009 [Page 7]
Internet-Draft Routing Metrics for LLNs October 2008
Some applications may make use of the aggregation node attribute in
their routing decision so as to minimize the amount of traffic on the
network, thus potentially increasing its life time in battery
operated environments.
To make data aggregation possible, the routing protocol needs to
capture the time and location dependent correlation among sensed data
from nodes on the possible routes, which may be challenging.
Obtaining correlation structure also demands high resource (energy)
consumption and in-network processing itself may have high
complexity. Consequently, in most applications, data aggregation may
not be adopted for routing. Applications where high directional data
flow is expected in a regular basis may take advantage of data
aggregation supported routing.
4.6. Node degree
Node degree is the number of neighbors that can receive a message
from the node directly. In other words, neighbors are nodes located
within the transmission range of the node. Note that not all the
neighbors may be able to send a message to the node directly in the
presence of asymmetric links. Generally, a high node degree can be
helpful for quick path recovery when the next hop node on the path
fails. Therefore, it may be beneficial to select a node with a high
degree when computing a path. On the other hand, a node with a high
degree has a high possibility to suffer from high workload in a
congested network. Therefore, node degree has to be carefully
utilized in routing decision.
4.7. Dynamicity
Node dynamicity can be measured by many different factors such as
mobility, transmission range, duty cycle, and the rate at which node
joins and leaves the network. Node dynamicity directly affects the
network topology and connectivity, which in turn may trigger path re-
computation. For that reason, node dynamicity needs to be monitored
and quantified utilizing a well defined objective function. Thus,
less dynamic nodes should be preferred for path selection. In the
most constrained LLN environments, the simple heuristic of
classifying nodes into static and dynamic can be very helpful in
routing decision. Node dynamicity may either be a static or a
dynamic metric.
4.8. Node reliability
Node reliability refers to the node failure rate. It is usually very
challenging to estimate or monitor node reliability and historical
data can be used to that end. A specific function needs to be
Kim, Vasseur et al. Expires April 19, 2009 [Page 8]
Internet-Draft Routing Metrics for LLNs October 2008
defined to get values of the reliability metric from a variety of
features affecting node reliability.
A sleeping node should not be an intermediate node to deliver a
packet, thus status of a node must be monitored or should be
predictable. Additionally, residual energy of a node should be
predictable not to make the node suddenly die during routing process
due to battery out. Nodes on the chosen path for routing should be
reliable.
5. Link metrics and attributes
There are several dynamic link attributes especially in wireless
LLNs. Even in case of fixed LLNs where nodes are stationary, link
qualities may greatly vary in the presence of obstacles and signal
interference. That being said, as for node metrics and attributes,
link metrics and attributes may be considered as static in fixed LLNs
not only because it is very challenging to update them in real-time
but also because updating mechanisms may be too time and energy
consuming. However, in mobile LLNs, we may need to consider these
metrics and attributes as dynamic.
5.1. Bandwidth
The link bandwidth can be considered as a link capacity metric. It
must be remembered that in case of wireless link, the link capacity
is shared among nodes in a single wireless link and is a dynamic
metric.
5.2. Reliability (Quality)
Link reliability can be measured by the Bit Error Rate (BER), Mean
Time Between Failures (MTBF) or link churn, the rate at which links
see their status changed (up or down). Link reliability is closely
related to node reliability especially in wireless LLNs. Two nodes
which form a link affect directly to the link reliability as follows:
if one (or both) end node of the link dies or moves away beyond of
the transmission range from the other node, the link vanishes and
should be removed from routing. However, link reliability is also
influenced by other factors like unexpected obstacles or temporary
interference.
Just like node reliability is critical, link reliability is also
essential for routing given that most nodes have very short duty
cycles. A change in link quality can effect network connectivity.
Therefore, link quality may be taken into account as a critical
routing metric. As mentioned earlier, link quality metric should be
Kim, Vasseur et al. Expires April 19, 2009 [Page 9]
Internet-Draft Routing Metrics for LLNs October 2008
applied to each directional link unless bi-directionality is one of
routing metrics. Since path reliability is a function of each link
and node reliability, such metrics may become critical as path length
increases.
5.3. Propagation delay
Propagation delay is the time taken for the packet to traverse the
link from the source node to the target node. Path latency is the
sum of all nodes' latencies and all links!_ propagation delays along
the path. As mentioned earlier, propagation delay can be obtained by
averaging historical data.
5.4. Bi-directionality
Real radio systems in the field have asymmetric links for a few
reasons. Two devices with different radio coverage or transmission
power will experience asymmetry in the reliability of the link
between them. Moreover, same types of devices often have asymmetric
links due to manufacturing variances in the radios. Since many
routing algorithms actually construct paths using links in the
reverse direction, a routing path may be created that is functional
in the destination to source direction, but not in the forward
direction. Routing protocols should detect asymmetrical links and
construct paths using forwards links instead of reverse links.
Therefore, bi-directionality is another important factor to consider
link attributes as routing metrics. There are two options to take
care of this issue. One is making bi-directionality one of routing
metrics (probably as a link attribute). This is quite challenging
since deciding whether a link is symmetric or not is not easy. The
other way is that directional links should be considered when related
metrics is used for path calculation. The latter option means, for
instance, propagation delay or link reliability should be associated
with each directional link. Thus, any opposite directional two links
connecting two nodes may have different link attributes.
5.5. Link Coloring
Link color is an administrative static attribute used to avoid or
attract specific links for specific traffic types.
6. Computation of dynamic metrics and attributes
As already pointed out, dynamically calculated metrics are of the
utmost importance in many circumstances in LLNs. This is mainly
because a variety of metrics change on a frequent basis, thus
implying the need to adapt the routing decisions. That being said,
Kim, Vasseur et al. Expires April 19, 2009 [Page 10]
Internet-Draft Routing Metrics for LLNs October 2008
careful care must be given to the pace at which such metrics and
attributes change.
Algorithms used to compute such metrics MUST use multi-threshold
mechanisms with low and high water marks for binary values and a
limited set of discrete metric values for non binary metric.
Furthermore, it is RECOMMENDED to use a low-pass filter to avoid
rapid fluctuations of these values. Finally, although the
specification of path computation algorithms using dynamic metrics
are out the scope of this document, it is RECOMMENDED to design the
objective function carefully to avoid too frequent computation of new
routes upon metric values changes.
Controlled adaptation of the routing metrics and rate at which path
are computed are critical to avoid undesirable routing instabilities
resulting in increased latencies and packet loss because of temporary
micro-loops. Furthermore, since LLNs are made of constrained
devices, computational resources must be used with care to preserve
battery in case of battery operated devices and not to impact quality
of service of the data traffic.
7. Open issues
Other items to be addressed in further revisions of this document
include:
o Metrics related to security: Metrics that security is associated
with need to be further considered. If a route is comprised of
authenticated and authorized nodes for the data, then the route
may be preferable.
o Consideration of routing efficiency and stability: Since LLNs are
highly constrained networks, maintaining many different routing
metrics is challenging. Routing should be lightweight. In
addition, careful condition should be given to the dynamic nature
of some metrics and their implication on routing stability.
8. Metric consistency
Since a set of metrics and attributes will be used for links and
nodes in LLN, it is particularly critical to ensure the use of
consistent metric calculation mechanisms for all links and nodes in
the network. Although this is applicable to all routing scheme, a
number of such metrics and attributes in LLN makes it particularly
challenging.
Kim, Vasseur et al. Expires April 19, 2009 [Page 11]
Internet-Draft Routing Metrics for LLNs October 2008
9. Security Considerations
Routing metrics should be handled in a secure and trustful manner.
For instance, a malicious node can not advertise falsely that it has
good metrics for routing and belong to the established path to have a
chance to intercept packets.
10. IANA Considerations
This document requests no action by IANA.
11. Acknowledgements
The authors would like to acknowledge the contributions of Dr.
YoungJae Kim and David Meyer for their review and comments.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[I-D.ietf-roll-indus-routing-reqs]
Networks, D., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-indus-routing-reqs-01 (work in
progress), July 2008.
[I-D.ietf-roll-terminology]
Vasseur, JP., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-02 (work in
progress), September 2008.
[Khanna89] Khanna, A., and Zinky, J.,"The revised ARPANET routing
metric", ACM SIGCOMM, Austin, USA, Sept. 1989, pp. 45-56.
[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
Kim, Vasseur et al. Expires April 19, 2009 [Page 12]
Internet-Draft Routing Metrics for LLNs October 2008
Authors' Addresses
Mijeom Kim (editor)
Future Tech Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-6063
Fax: +82-2-526-5071
Email: mjkim@kt.com
JP Vasseur (editor)
Cisco Systems
11, Rue Camille Desmoulins
L'Atlantis 92782 Issy Les Moulineaux
France
Email: jpv@cisco.com
Hakjin Chong
Future Tech Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5070
Fax: +82-2-526-5071
Email: hjchong@kt.com
Kim, Vasseur et al. Expires April 19, 2009 [Page 13]
Internet-Draft Routing Metrics for LLNs October 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.
Kim, Vasseur et al. Expires April 19, 2009 [Page 14]