draft-ietf-mpls-ldp-igp-sync-00.txt | draft-ietf-mpls-ldp-igp-sync-01.txt | |||
---|---|---|---|---|
Network Working Group M. Jork | Network Working Group M. Jork | |||
Internet-Draft Reef Point | Internet Draft NextPoint Networks | |||
Expires: March 9, 2008 A. Atlas | Category: Informational Alia Atlas | |||
Expires: August 2008 British Telecom | ||||
L. Fang | L. Fang | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
September 6, 2007 | ||||
February 2008 | ||||
LDP IGP Synchronization | LDP IGP Synchronization | |||
draft-ietf-mpls-igp-sync-00 | draft-ietf-mpls-ldp-igp-sync-01.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six | |||
and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other | |||
time. It is inappropriate to use Internet-Drafts as reference | documents at any time. It is inappropriate to use Internet-Drafts | |||
material or to cite them other than as "work in progress." | as reference material or to cite them other than as "work in | |||
progress." | ||||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on March 9, 2008. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | ||||
Copyright (C) The IETF Trust (2007). | ||||
Abstract | Abstract | |||
In networks depending on edge-to-edge establishment of MPLS | In certain networks there is a dependency on edge-to-edge LSPs setup | |||
forwarding paths via LDP, blackholing of traffic can occur in | by LDP, e.g. networks that are used for MPLS VPN applications. For | |||
situations where the IGP is operational on a link and thus the link | such applications it is not possible to rely on IP forwarding if the | |||
is used for IP forwarding but LDP is not operational on that link for | MPLS LSP is not operating appropriately. Blackholing of labeled | |||
whatever reason. This document describes a mechanism to avoid | ||||
traffic loss due to this condition without introducing any protocol | M. Jork, A. Atlas, and L. Fang | |||
changes. | 1 | |||
LDP IGP Synchronization February 2008 | ||||
traffic can occur in situations where the IGP is operational on a | ||||
link but LDP is not operational on that link. While the link could | ||||
still be used for IP forwarding, it is not useful for traffic with | ||||
packets carrying a label stack of more than one label or when the IP | ||||
address carried in the packet is out of the RFC1918 space. This | ||||
document describes a mechanism to avoid traffic loss due to this | ||||
condition without introducing any protocol changes. | ||||
Table of Contents | ||||
1. Introduction..................................................2 | ||||
2. Proposed Solution.............................................3 | ||||
3. Applicability.................................................4 | ||||
4. Interaction With TE Tunnels...................................5 | ||||
5. Security Considerations.......................................5 | ||||
6. IANA Considerations...........................................5 | ||||
7. Normative References..........................................6 | ||||
8. Informational References......................................6 | ||||
9. Author's Addresses............................................6 | ||||
10. Acknowledgements............................................8 | ||||
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 [RFC | ||||
2119]. | ||||
1. Introduction | 1. Introduction | |||
LDP [RFC3036] establishes MPLS LSPs along the shortest path to a | LDP [RFC5036] establishes MPLS LSPs along the shortest path to a | |||
destination as determined by IP forwarding. In a common network | destination as determined by IP forwarding. In a common network | |||
design, LDP is used to provide label switched paths throughout the | design, LDP is used to provide label switched paths throughout the | |||
complete network domain covered by an IGP such as OSPF [RFC2328] or | complete network domain covered by an IGP such as OSPF [RFC2328] or | |||
IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as well | IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as | |||
as LDP adjacencies. | well as LDP adjacencies. | |||
A variety of services a network provider may want to deploy over an | A variety of services a network provider may want to deploy over an | |||
LDP enabled network depend on the availability of edge to edge label | LDP enabled network depend on the availability of edge to edge | |||
switched paths. In a L2 or L3 VPN scenario for example, a given PE | label switched paths. In a L2 or L3 VPN scenario for example, a | |||
router relies on the availability of a complete MPLS forwarding path | given PE router relies on the availability of a complete MPLS | |||
to the other PE routers for the VPNs it serves. This means that | forwarding path to the other PE routers for the VPNs it serves. | |||
along the IP shortest path from one PE router to the other, all the | ||||
links need to have operational LDP sessions and the necessary label | ||||
binding must have been exchanged over those sessions. If only one | ||||
link along the IP shortest path is not covered by an LDP session, a | ||||
blackhole exists and services depending on MPLS forwarding will fail. | ||||
This might be a transient or a persistent error condition. Some of | ||||
the reasons for it could be | ||||
o a configuration error, | M. Jork, Alia Atlas, and L. Fang 2 | |||
LDP IGP Synchronization February 2008 | ||||
o an implementation bug, | This means that along the IP shortest path from one PE router to | |||
the other, all the links need to have operational LDP sessions and | ||||
the necessary label binding must have been exchanged over those | ||||
sessions. If only one link along the IP shortest path is not | ||||
covered by an LDP session, a blackhole exists and services | ||||
depending on MPLS forwarding will fail. This might be a transient | ||||
or a persistent error condition. Some of the reasons for it could | ||||
be | ||||
o the link has just come up and has an IGP adjacency but LDP has | - A configuration error | |||
either not yet established an adjacency or session or distributed | ||||
all the label bindings. | - An implementation bug | |||
- The link has just come up and has an IGP adjacency but LDP has | ||||
either not yet established an adjacency or session or | ||||
distributed all the label bindings. | ||||
The LDP protocol itself has currently no means to indicate to a | The LDP protocol itself has currently no means to indicate to a | |||
service depending on it whether there is an uninterrupted label | service depending on it whether there is an uninterrupted label | |||
switched path available to the desired destination or not. | switched path available to the desired destination or not. | |||
2. Proposed Solution | 2. Proposed Solution | |||
The problem described above exists because LDP is tied to IP | The problem described above exists because LDP is tied to IP | |||
forwarding decisions but no coupling between the IGP and LDP | forwarding decisions but no coupling between the IGP and LDP | |||
operational state on a given link exists. If IGP is operational on a | operational state on a given link exists. If IGP is operational on | |||
link but LDP is not, a potential network problem exists. So the | a link but LDP is not, a potential network problem exists. So the | |||
solution described by this document is to prevent a link from being | solution described by this document is to discourage a link from | |||
used for IP forwarding as long as LDP is not fully operational. This | being used for IP forwarding as long as LDP is not fully | |||
has some similarity to the mechanism specified in [RFC3137] which | operational. | |||
allows an OSPF router to advertise that it should not be used as a | ||||
transit router. One difference is that [RFC3137] raises the link | ||||
costs on all (stub) router links, while the mechanism described in | ||||
here applies on a per-link basis. | ||||
In detail: when LDP is not "fully operational" (see below) on a given | This has some similarity to the mechanism specified in [RFC3137] | |||
link, the IGP will advertise the link with maximum cost to avoid any | which allows an OSPF router to advertise that it should not be used | |||
transit traffic over it if possible. In the case of OSPF this cost | as a transit router. One difference is that [RFC3137] raises the | |||
is LSInfinity (16-bit value 0xFFFF) as proposed in [RFC3137]. Note | link costs on all (stub) router links, while the mechanism | |||
that the link is not just simply removed from the topology because | described in here applies on a per-link basis. | |||
LDP depends on the IP reachability to establish its adjacency and | ||||
session. Also, if there is no other link in the network to reach a | In detail: when LDP is not "fully operational" (see below) on a | |||
particular destination, no additional harm is done by making this | given link, the IGP will advertise the link with maximum cost to | |||
link available for IP forwarding at maximum cost. | avoid any transit traffic over it if possible. In the case of OSPF | |||
this cost is LSInfinity (16-bit value 0xFFFF) as proposed in | ||||
[RFC3137]. Note that the link is not just simply removed from the | ||||
topology because LDP depends on the IP reachability to establish | ||||
its adjacency and session. Also, if there is no other link in the | ||||
network to reach a particular destination, no additional harm is | ||||
done by making this link available for IP forwarding at maximum | ||||
cost. | ||||
M. Jork, Alia Atlas, and L. Fang 3 | ||||
LDP IGP Synchronization February 2008 | ||||
LDP is considered fully operational on a link when an LDP hello | LDP is considered fully operational on a link when an LDP hello | |||
adjacency exists on it, a suitable associated LDP session (matching | adjacency exists on it, a suitable associated LDP session (matching | |||
the LDP Identifier of the hello adjacency) is established to the peer | the LDP Identifier of the hello adjacency) is established to the | |||
at the other end of the link and all label bindings have been | peer at the other end of the link and all label bindings have been | |||
exchanged over the session. The latter condition can not generally | exchanged over the session. The latter condition can not generally | |||
be verified by a router and some heuristics may have to be used. A | be verified by a router and some heuristics may have to be used. A | |||
simple implementation strategy is to wait some time after LDP session | simple implementation strategy is to wait some time after LDP | |||
establishment before declaring LDP fully operational in order to | session establishment before declaring LDP fully operational in | |||
allow for the exchange of label bindings. This is typically | order to allow for the exchange of label bindings. This is | |||
sufficient to deal with the link when it is being brought up. LDP | typically sufficient to deal with the link when it is being brought | |||
protocol extensions to indicate the complete transmission of all | up. LDP protocol extensions to indicate the complete transmission of | |||
currently available label bindings after a session has come up are | all currently available label bindings after a session has come up | |||
conceivable but not addressed in this document. | are conceivable but not addressed in this document. | |||
The mechanism described in this document does not entail any protocol | The mechanism described in this document does not entail any | |||
changes and is a local implementation issue. However, it is | protocol changes and is a local implementation issue. However, it | |||
recommended that both sides of a link implement this mechanism to be | is recommended that both sides of a link implement this mechanism | |||
effective and to avoid asymmetric link costs which could cause | to be effective and to avoid asymmetric link costs which could | |||
problems with IP multicast forwarding. | cause problems with IP multicast forwarding. | |||
The problem space and solution specified in this document have also | The problem space and solution specified in this document have also | |||
been discussed in an IEEE Communications Magazine paper [LDP-Fail]. | been discussed in an IEEE Communications Magazine paper [LDP-Fail]. | |||
3. Applicability | 3. Applicability | |||
In general, the proposed procedure is applicable in networks where | ||||
the availability of LDP signaled MPLS LSPs and avoidance of | ||||
blackholes for MPLS traffic is more important than always choosing | ||||
an optimal path for IP forwarded traffic. Note however that non- | ||||
optimal IP forwarding only occurs for a short time after a link | ||||
comes up or when there is a genuine problem on a link. In the | ||||
latter case an implementation should issue network management alerts | ||||
to report the error condition and enable the operator to address it. | ||||
Example network scenarios that benefit from the mechanism described | Example network scenarios that benefit from the mechanism described | |||
in here are MPLS VPNs and BGP-free core network designs where traffic | here are MPLS VPNs and BGP-free core network designs where traffic | |||
can only be forwarded through the core when LDP forwarding state is | can only be forwarded through the core when LDP forwarding state is | |||
available throughout. | available throughout. | |||
In general, the proposed procedure is applicable in networks where | The usefulness of this mechanism also depends on the availability | |||
the availability of LDP signaled MPLS LSPs and avoidance of | of alternate paths with sufficient bandwidth in the network should | |||
blackholes for MPLS traffic is more important than always choosing an | one link be assigned to the maximum cost due to unavailability of | |||
optimal path for IP forwarded traffic. Note however that non-optimal | LDP service over it. | |||
IP forwarding only occurs for a short time after a link comes up or | ||||
when there is a genuine problem on a link. In the latter case an | ||||
implementation should issue network management alerts to report the | ||||
error condition and enable the operator to address it. | ||||
The usefulness of this mechanism also depends on the availability of | ||||
alternate paths with sufficient bandwidth in the network should one | ||||
link get costed out due to unavailability of LDP service over it. | ||||
On broadcast links with more than one IGP/LDP peer, the cost-out | On broadcast links with more than one IGP/LDP peer, the cost-out | |||
procedure can only be applied to the link as a whole and not an | procedure can only be applied to the link as a whole and not an | |||
individual peer. So a policy decision has to be made whether the | individual peer. So a policy decision has to be made whether the | |||
M. Jork, Alia Atlas, and L. Fang 4 | ||||
LDP IGP Synchronization February 2008 | ||||
unavailability of LDP service to one peer should result in the | unavailability of LDP service to one peer should result in the | |||
traffic being diverted away from all the peers on the link. | traffic being diverted away from all the peers on the link. | |||
4. Interaction With TE Tunnels | 4. Interaction With TE Tunnels | |||
In some networks, LDP is used in conjunction with RSVP-TE which sets | In some networks, LDP is used in conjunction with RSVP-TE which sets | |||
up traffic-engineered tunnels. The path computation for the TE | up traffic-engineered tunnels. The path computation for the TE | |||
tunnels is based on the TE link cost which is flooded by the IGP in | tunnels is based on the TE link cost which is flooded by the IGP in | |||
addition to the regular IP link cost. The mechanism described in | addition to the regular IP link cost. The mechanism described in | |||
this document should only be applied to the IP link cost to prevent | this document should only be applied to the IP link cost to prevent | |||
any unnecessary TE tunnel reroutes. | any unnecessary TE tunnel reroutes. | |||
In order to establish LDP LSPs across a TE tunnel, a targeted LDP | In order to establish LDP LSPs across a TE tunnel, a targeted LDP | |||
session between the tunnel endpoints needs to exist. This presents a | session between the tunnel endpoints needs to exist. This presents | |||
problem very similar to the case of a regular LDP session over a link | a problem very similar to the case of a regular LDP session over a | |||
(the case discussed so far): when the TE tunnel is used for IP | link (the case discussed so far): when the TE tunnel is used for IP | |||
forwarding, the targeted LDP session needs to be operational to avoid | forwarding, the targeted LDP session needs to be operational to | |||
LDP connectivity problems. Again, raising the IP cost of the tunnel | avoid LDP connectivity problems. Again, raising the IP cost of the | |||
while there is no operational LDP session will solve the problem. | tunnel while there is no operational LDP session will solve the | |||
When there is no IGP adjacency over the tunnel and the tunnel is not | problem. When there is no IGP adjacency over the tunnel and the | |||
advertised as link into the IGP, this becomes a local issue of the | tunnel is not advertised as link into the IGP, this becomes a local | |||
tunnel headend router. | issue of the tunnel headend router. | |||
5. Security Considerations | 5. Security Considerations | |||
A DoS attack that brings down LDP service on a link or prevents it | A DoS attack brings down LDP service on a link or prevents it from | |||
from becoming operational on a link will now additionally cause non- | becoming operational on a link could be one of the possibilities | |||
optimal IP forwarding within the network. However, as discussed | that causes LDP related traffic blackholing. This document does not | |||
above this is considered beneficial as it prevents MPLS traffic from | address how to prevent LDP session failure. The mechanism described | |||
being dropped. | here is to prevent the link to be used when LDP is not operational | |||
while IGP is. Assigning the IGP cost to maximum on the link where | ||||
LDP is failed and IGP is not should not introduce new security | ||||
threats. The operation is internal in the router to allow LDP and | ||||
IGP to communicate and react. Making many LDP links unavailable, | ||||
however, is a security threat which can cause traffic being dropped | ||||
due to limited available network capacity. This may be trigged by | ||||
operational error or implementation error. They are considered as | ||||
general Security issues and should follow the current best security | ||||
practice. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
7. References | M. Jork, Alia Atlas, and L. Fang 5 | |||
LDP IGP Synchronization February 2008 | ||||
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and | 7. Normative References | |||
B. Thomas, "LDP Specification", RFC 3036, January 2001. | ||||
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., | ||||
and B. Thomas, "LDP Specification", RFC 5036, October 2007. | ||||
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | |||
8. Informational References | ||||
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | |||
McPherson, "OSPF Stub Router Advertisement", RFC 3137, | McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001. | |||
June 2001. | ||||
[ISO.10589.1992] | [ISO.10589.1992]International Organization for | |||
International Organization for Standardization, | Standardization,"Intermediate system to intermediate system intra- | |||
"Intermediate system to intermediate system intra-domain- | domain-routing routine information exchange protocol for use in | |||
routing routine information exchange protocol for use in | conjunction with the protocol for providing the connectionless-mode | |||
conjunction with the protocol for providing the | Network Service (ISO 8473)", ISO Standard 10589, 1992. | |||
connectionless-mode Network Service (ISO 8473)", | ||||
ISO Standard 10589, 1992. | ||||
[LDP-Fail] | [LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and | |||
Fang, L., Atlas, A., Chiussi, F., Kompella, K., and G. | Swallow, G., "LDP Failure Detection and Recovery", IEEE | |||
Swallow, "LDP Failure Detection and Recovery", IEEE | Communications Magazine, Vol.42, No.10, October 2004. | |||
Communications Vol.42 No.10, October 2004. | ||||
Authors' Addresses | 9. Author's Addresses | |||
Markus Jork | Markus Jork | |||
Reef Point Systems | NextPoint Networks | |||
8 New England Executive Park | 3 Fedral St. | |||
Burlington, MA 01803 | Billerica, MA 01821 | |||
US | USA | |||
Email: mjork@nextpointnetworks.com | ||||
Phone: +1 781 359 5071 | ||||
Email: mjork@reefpoint.com | ||||
Alia Atlas | Alia Atlas | |||
Google, Inc. | British Telecom | |||
One Broadway, 7th Floor | Email: alia.atlas@bt.com | |||
Cambridge, MA 02142 | ||||
US | ||||
Email: akatlas@google.com | ||||
Luyuan Fang | Luyuan Fang | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
300 Beaver Brook Road | 300 Beaver Brook Road | |||
Boxborough, MA 01719 | Boxborough, MA 01719 | |||
US | USA | |||
Email: lufang@cisco.com | Email: lufang@cisco.com | |||
Intellectual Property | ||||
M. Jork, Alia Atlas, and L. Fang 6 | ||||
LDP IGP Synchronization February 2008 | ||||
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. | ||||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | |||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | |||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | |||
FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | Intellectual Property | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed | |||
pertain to the implementation or use of the technology described in | to pertain to the implementation or use of the technology described | |||
this document or the extent to which any license under such rights | in this document or the extent to which any license under such | |||
might or might not be available; nor does it represent that it has | rights might or might not be available; nor does it represent that | |||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | M. Jork, Alia Atlas, and L. Fang 7 | |||
found in BCP 78 and BCP 79. | LDP IGP Synchronization February 2008 | |||
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 | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | 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 | attempt made to obtain a general license or permission for the use | |||
such proprietary rights by implementers or users of this | of such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository | |||
http://www.ietf.org/ipr. | at http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at ietf- | |||
ietf-ipr@ietf.org. | ipr@ietf.org. | |||
Acknowledgment | 10. Acknowledgements | |||
Funding for the RFC Editor function is provided by the IETF | Funding for the RFC Editor function is provided by the IETF | |||
Administrative Support Activity (IASA). | Administrative Support Activity (IASA). | |||
The authors would like to thank Loa Andersson for his review and | ||||
comments. | ||||
M. Jork, Alia Atlas, and L. Fang 8 | ||||
End of changes. 43 change blocks. | ||||
154 lines changed or deleted | 233 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |