Networking Working Group Matthew. Meyer, Ed.
Internet-Draft British Telecom
Intended status: Standards Track JP. Vasseur, Ed.
Expires: March 5, 2009 Cisco Systems, Inc
September 1, 2008
MPLS Traffic Engineering Soft Preemption
draft-ietf-mpls-soft-preemption-12.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 March 5, 2009.
Abstract
This document specifies Multiprotocol Label Switching (MPLS) Traffic
Engineering Soft Preemption, a suite of protocol modifications
extending the concept of preemption with the goal of reducing/
eliminating traffic disruption of preempted Traffic Engineering Label
Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined
supporting only immediate TE LSP displacement upon preemption. The
utilization of a reroute request notification helps more gracefully
mitigate the re-route process of preempted TE LSP. For the brief
period soft preemption is activated, reservations (though not
necessarily traffic levels) are in effect under-provisioned until the
TE LSP(s) can be re-routed. For this reason, the feature is
Meyer & Vasseur Expires March 5, 2009 [Page 1]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
primarily but not exclusively interesting in MPLS enabled IP networks
with Differentiated Services and Traffic Engineering capabilities.
Requirements Language
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 RFC 2119 [RFC2119].
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 3
1.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SESSION-ATTRIBUTE Flags . . . . . . . . . . . . . . . . . 5
4.2. Path Error - "Reroute request Soft Preemption" Error
Value . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 5
6. Elements Of Procedures . . . . . . . . . . . . . . . . . . . . 7
6.1. On a Soft Preempting LSR . . . . . . . . . . . . . . . . . 7
6.2. On Head-end LSR of a Soft Preempted TE LSP . . . . . . . . 9
7. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 9
8. Management . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. New Session Attribute Object Flag . . . . . . . . . . . . 10
9.2. New error sub-code value . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Meyer & Vasseur Expires March 5, 2009 [Page 2]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
1. Terminology
This document follows the nomenclature of the MPLS Architecture
defined in [RFC3031].
1.1. Acronyms and Abbreviations
CSPF: Constrained Shortest Path First.
DS: Differentiated Services.
LER: Label Edge Router.
LSR: Label Switching Router.
LSP: Label Switched Path.
MPLS: MultiProtocol Label Switching.
RSVP: Resource ReSerVation Protocol.
TE LSP: Traffic Engineering Label Switched Path.
1.2. Nomenclature
Point of Preemption - the midpoint or ingress LSR which due to RSVP
provisioning levels is forced to either hard preempt or under-
provision and signal soft preemption.
Hard Preemption - The (typically default) preemption process in which
higher numeric priority TE LSPs are intrusively displaced at the
point of preemption by lower numeric priority TE LSPs. In hard
preemption the TE LSP is torn down before reestablishment.
2. Motivations
Initially Multiprotocol Label Switching (MPLS) RSVP-TE [RFC3209] was
defined supporting only one method of TE LSP preemption which
immediately tears down TE LSPs, disregarding the preempted in-transit
traffic. This simple but abrupt process nearly guarantees preempted
traffic will be discarded, if only briefly, until the RSVP Path Error
message reaches and is processed by the ingress LER and a new data
path can be established. The Error Code and Error Values carried
within the RSVP Path Error message to report a preemption action are
documented in [I-D.ietf-mpls-3209-patherr]. Note that such
preemption is also referred to as a fatal error in
[I-D.ietf-mpls-3209-patherr]. In cases of actual resource contention
Meyer & Vasseur Expires March 5, 2009 [Page 3]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
this might be helpful, however preemption may be triggered by mere
reservation contention and reservations may not reflect data plane
contention up to the moment. The result is that when conditions that
promote preemption exist and hard preemption is the default behavior,
inferior priority preempted traffic may be needlessly discarded when
sufficient bandwidth exists for both the preempted Traffic
Engineering Labeled Switched Path (TE LSP) and the preempting TE
LSP(s).
Hard preemption may be a requirement to protect numerically lower
preemption priority traffic in a non Diff-Serv enabled architecture,
but in a Diff-Serv enabled architecture, one need not rely
exclusively upon preemption to enforce a preference for the most
valued traffic since the marking and queuing disciplines should
already be aligned for those purposes. Moreover, even in non Diff-
Serv aware networks, depending on the TE LSP sizing rules (imagine
all LSPs are sized at double their observed traffic level),
reservation contention may not accurately reflect the potential for
data plane congestion.
3. Introduction
In an MPLS RSVP-TE (see [RFC3209]) enabled IP network, hard
preemption is the default behavior. Hard preemption provides no
mechanism to allow preempted TE LSPs to be handled in a make-before-
break fashion: the hard preemption scheme instead utilizes a very
intrusive method that can cause traffic disruption for a potentially
large amount of TE LSPs. Without an alternative, network operators
either accept this limitation, or remove functionality by using only
one preemption priority or using invalid bandwidth reservation
values. Understandably desirable features like ingress LER automated
TE reservation adjustments are less palatable when preemption is
intrusive and high network stability levels are a concern.
This document defines the use of additional signaling and maintenance
mechanisms to alert the ingress LER of the preemption that is pending
and allow for temporary control plane under-provisioning while the
preempted tunnel is re-routed in a non disruptive fashion (make-
before-break) by the ingress LER. During the period that the tunnel
is being re-routed, link capacity is under-provisioned on the
midpoint where preemption initiated and potentially one or more links
upstream along the path where other soft preemptions may have
occurred.
Meyer & Vasseur Expires March 5, 2009 [Page 4]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
4. RSVP Extensions
4.1. SESSION-ATTRIBUTE Flags
To explicitly signal the desire for a TE LSP to benefit from the soft
preemption mechanism (and so not to be hard preempted if the soft
preemption mechanism is available), the following flag of the
SESSION-ATTRIBUTE object (for both the C-Type 1 and 7) is defined:
Soft Preemption Desired bit
Bit Flag Name Flag
0x40 Soft Preemption Desired
4.2. Path Error - "Reroute request Soft Preemption" Error Value
[I-D.ietf-mpls-gmpls-lsp-reroute] specifies defines a new reroute-
specific error code that allows a mid-point to report a TE LSP
reroute request (Error-code=34 - Reroute). This document specifies a
new error sub-code value for the case of Soft Preemption (to be
confirmed by IANA upon publication of this document).
Error-value Meaning Reference
1 Reroute Request Soft Preemption This document
Upon (soft) preemption, the preemting node MUST issue a PathErr
message with the error code=34 ("Reroute") and a value=1 ("Reroute
request soft preemption"), to be confirmed by IANA. If the local
request directs a reroute around the local node, the error value
"Local node maintenance required" MUST be used and the local node
MUST be indicated in the ERROR_SPEC object. This indicates to the
ingress LER of this LSP that it SHOULD be re-routed.
5. Mode of Operation
Let's consider the following example:
Meyer & Vasseur Expires March 5, 2009 [Page 5]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
R0--1G--R1---155----R2
| \ |
| \ 155
| \ |
155 1G R3
| \ |
| \ 155
| \|
R4----1G----R5
LSP1: LSP2:
R0-->R1 R1<--R2
\ |
V V
R5 R4
Figure 1: Example of Soft Preemption Operation
In the network depicted above in figure 1, consider the following
conditions:
o Reservable BW on R0-R1, R1-R5 and R4-R5 is 1Gb/sec.
o Reservable BW on R1-R2, R1-R4, R2-R3, R3-R5 is 155 Mb/sec.
o Bandwidths and costs are identical in both directions.
o Each circuit has an IGP metric of 10 and IGP metric is used by
CSPF.
o Two TE tunnels are defined: - LSP1: 155 Mb, setup/hold priority 0
tunnel, path R0-R1-R5. - LSP2: 155 Mb, setup/hold priority 7
tunnel, path R2-R1-R4. Both TE LSPs are signaled with the soft
preemption desired bit of their SESSION-ATTRIBUTE object set.
o Circuit R1-R5 fails
o Soft Preemption is functional.
When the circuit R1-R5 fails, R1 detects the failure and sends an
updated IGP LSA/LSP and Path Error message to all the head-end LSRs
having a TE LSP traversing the failed link (R0 in the example above).
Either form of notification may arrive at the head-end LSRs first.
Upon receiving the link failure notification, R0 triggers a TE LSP
re-route of LSP1, and re-signals LSP1 along shortest path available
Meyer & Vasseur Expires March 5, 2009 [Page 6]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
satisfying the TE LSP constraints: R0-R1-R4-R5 path. The Resv
messages for LSP1 travel in the upstream direction (from the
destination to the head-end LSR - R5 to R0 in this example). LSP2 is
soft preempted at R1 as it has a numerically lower priority value and
both bandwidth reservations cannot be satisfied on the R1-R4 link.
Instead of sending a path tear for LSP2 upon preemption as with hard
preemption (which would result in an immediate traffic disruption for
LSP2), R1s local bandwidth accounting for LSP2 is zeroed and a
PathErr message with error code "Notify" and a value "Reroute request
soft preemption" for LSP2 is issued.
Upon reception of the PathErr message for LSP2, R2 may update the
working copy of the TE-DB before running calculating a new path for
the new LSP. In the case that Diff-Serv [RFC3270] and TE [RFC3209]
are deployed, receiving a preemption pending notification may imply
to a head-end LSR that the available bandwidth for the affected
priority level and numerically greater priority levels has been
exhausted for the indicated node interface. R2 may choose to reduce
or zero available bandwidth for the implied priority range until more
accurate information is available (i.e. a new IGP TE update is
received). It follows that R2 re-computes a new path and performs a
non traffic disruptive rerouting of the new TE LSP T2 by means of the
make-before-break procedure. The old path is then torn down.
6. Elements Of Procedures
6.1. On a Soft Preempting LSR
When a new TE LSP is signaled which requires to preempt a set of TE
LSP(s) because not all TE LSPs can be accommodated on a specific
interface, a node triggers a preemption action which consists of
selecting the set of TE LSPs that must be preempted so as to free up
some bandwidth in order to satisfy the newly signaled numerically
lower preemption TE LSP.
For each preempted TE LSP, instead of sending an RSVP Path Tear
message after the receipt of an RSVP PathErr message notifiying a
fatal action as documented in [I-D.ietf-mpls-3209-patherr] upon
preemption as with hard preemption (which would result in an
immediate traffic disruption for the preempted TE LSP), the
preempting node's local bandwidth accounting for the preempted TE LSP
is zeroed and a PathErr with error code "Notify" and a error value
"Reroute request soft preemption" for that TE LSP is issued upstream
toward the head-end LSR.
If more than one soft preempted TE LSP has the same head-end LSR,
Meyer & Vasseur Expires March 5, 2009 [Page 7]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
these soft preemption PathErr notification messages may be bundled
together.
The preempting node MUST immediately send a PathErr with error code
"Notify" and a error value "Reroute request soft preemption" for each
soft preempted TE LSP. The node MAY use the occurrence of soft
preemption to trigger an immediate IGP update or influence the
scheduling of an IGP update.
Should a refresh event for a soft preempted TE LSP arrive before the
soft preemption timer expires, the soft preempting node MUST continue
to refresh the TE LSP.
When the MESSAGE-ID extensions defined in [RFC2961] are available,
PathErr messages with error code "Notify" and a error value "Reroute
request soft preemption" SHOULD be sent in reliable mode.
To guard against a situation where bandwidth under-provisioning will
last forever, a local timer (named the "Soft preemption timer") MUST
be started on the preemption node, upon soft preemption. If this
timer expires, the preempting node SHOULD send an RSVP PathTear and
either a ResvTear message or a PathErr with the 'Path_State_Removed'
flag set.
The preempting node SHOULD first preempt the numerically higher
priority TE LSP(s) having their "Soft Preemption Desired" bit of the
SESSION ATTRIBUTE object cleared (TE LSP considered as Hard
Preemptable).
Selection of the preempted TE LSP at a preempting mid-point: when a
numerically lower priority TE LSP is signaled that requires the
preemption of a set of numerically higher priority LSPs, the node
where preemption is to occur has to make a decision on the set of TE
LSP(s), candidates for preemption. This decision is a local decision
and various algorithms can be used, depending on the objective (e.g,
see [RFC4829]). As already mentioned, soft preemption causes a
temporary link under provisioning condition while the soft preempted
TE LSPs are rerouted by their respective head-end LSRs. In order to
reduce this under provisioning exposure, a soft-preempting LSR MAY
check first if there exists soft preemptable TE LSP bandwidth flagged
by another node but still available for soft-preemption locally. If
sufficient overlap bandwidth exists the LSR MAY attempt to soft
preempt the same TE LSP. This would help reducing the temporarily
elevated under-provisioning ratio on the links where soft preemption
occurs and the number of preempted TE LSPs. Optionally, a midpoint
LSR upstream or downstream from a soft preempting node MAY choose to
flag the TE LSPs soft preempted state. In the event a local
preemption is needed, the relevant priority level LSPs from the cache
Meyer & Vasseur Expires March 5, 2009 [Page 8]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
are soft preempted first, followed by the normal soft and hard
preemption selection process for the given priority.
Under specific circumstances such as unacceptable link congestion, a
node MAY decide to hard preempt a TE LSP (by sending a fatal Path
Error message, a PathTear and either a ResvTear or a Path Error
message with the 'Path_State_Removed' flag set) even if its head-end
LSR explicitly requested 'soft preemption' ('Soft Preemption desired'
flag of the corresponding SESSION- ATTRIBUTE object set). Note that
such decision MAY also be taken for TE LSPs under soft preemption
state.
6.2. On Head-end LSR of a Soft Preempted TE LSP
Upon reception of a PathErr message with error code "Notify" and a
error value "Reroute request soft preemption", the head-end LSR MAY
first update the working copy of the TE-DB before computing a new
path (e.g by running CSPF) for the new LSP. In the case that Diff-
Serv [RFC3270] and MPLS Traffic Engineering [RFC3209] are deployed,
receiving preemption pending may imply to a head-end LSR that the
available bandwidth for the affected priority level and numerically
greater priority levels has been exhausted for the indicated node
interface. A head-end LSR MAY choose to reduce or zero available
bandwidth for the implied priority range until more accurate
information is available (i.e., a new IGP TE update is received).
Once a new path has been computed, the soft preempted TE LSP is
rerouted using the non traffic disruptive make-before-break
procedure.
As a result of soft preemption, no traffic will be needlessly black
holed due to mere reservation contention. If loss is to occur, it
will be due only to an actual traffic congestion scenario and
according to the operators Diff-Serv (if Diff-Serv is deployed) and
queuing scheme.
7. Interoperability
Backward compatibility should be assured as long as the
implementation followed the recommendations set forth in [RFC3209].
As mentioned previously, to guard against a situation where bandwidth
under-provisioning will last forever, a local timer (soft preemption
timer) MUST be started on the preemption node, upon soft preemption.
When this timer expires, the soft preempted TE LSP SHOULD be hard
preempted by sending a fatal Path Error message, a PathTear message
and either a ResvTear message or a PathErr message with the
Meyer & Vasseur Expires March 5, 2009 [Page 9]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
'Path_State_Removed' flag set. This timer SHOULD be configurable and
a default value of 30 seconds is RECOMMENDED.
It is RECOMMENDED that configuring the default preemption timer to 0
will cause the implementation to use hard-preemption.
Soft Preemption as defined in this document is designed for use in
MPLS RSVP-TE enabled IP Networks and may not functionally translate
to some GMPLS technologies. As with backward compatibility, if a
device does not recognize a flag, it should pass the subobject
transparently.
8. Management
Both the point of preemption and the ingress LER SHOULD provide some
form of accounting internally and to the network operator interface
with regard to which TE LSPs and how much capacity is under-
provisioned due to soft preemption. Displays of under-provisioning
are recommended for the following midpoint, ingress and egress views:
o Sum of current bandwidth per preemption priority per local
interface
o Sum of current bandwidth total per local interface
o Sum of current bandwidth total local router (ingress, egress,
midpoint)
o List current LSPs and bandwidth in PPend status
o List current sum bandwidth and session count in PPend status per
observed ERO hops (ingress, egress views only).
o Cumulative PPend events per observed ERO hops.
9. IANA Considerations
IANA will not need to create a new registry.
9.1. New Session Attribute Object Flag
A new flag of the Session Attribute object is defined (to be
confirmed by IANA)
Meyer & Vasseur Expires March 5, 2009 [Page 10]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
Soft Preemption Desired bit
Bit Flag Name Flag Reference
0x40 Soft Preemption Desired This document
9.2. New error sub-code value
[I-D.ietf-mpls-gmpls-lsp-reroute] specifies defines a new reroute-
specific error code that allows a mid-point to report a TE LSP
reroute request. This document specifies a new error sub-code value
for the case of Soft Preemption (to be confirmed by IANA upon
publication of this document).
Error-value Meaning Reference
1 Reroute Request Soft Preemption This document
10. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC3209]
remain relevant.
11. Acknowledgements
The authors would like to thank Carol Iturralde, Dave Cooper, Loa
Andersson, Arthi Ayyangar, Ina Minei, George Swallow and Adrian
Farrel for their valuable comments.
12. Authors' Addresses
The content of this document was contributed by the editors and the
co-authors listed below:
Meyer & Vasseur Expires March 5, 2009 [Page 11]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
Denver Maddux
Limelight Networks
USA
email: denver@nitrous.net
Curtis Villamizar
AVICI
curtis@faster-light.net
Amir Birjandi
Juniper Networks
2251 corporate park dr ste
herndon, VA 20171
USA
abirjandi@juniper.net
13. References
13.1. Normative References
[I-D.ietf-mpls-gmpls-lsp-reroute]
Berger, L., Papadimitriou, D., and J. Vasseur, "PathErr
Message Triggered MPLS and GMPLS LSP Reroute",
draft-ietf-mpls-gmpls-lsp-reroute-00 (work in progress),
August 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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.
13.2. Informative References
[I-D.ietf-mpls-3209-patherr]
Vasseur, J., Swallow, G., and I. Minei, "Node behavior
upon originating and receiving Resource ReserVation
Protocol (RSVP) Path Error message",
draft-ietf-mpls-3209-patherr-03 (work in progress),
August 2008.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Meyer & Vasseur Expires March 5, 2009 [Page 12]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 2008
Extensions", RFC 2961, April 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4829] de Oliveira, J., Vasseur, JP., Chen, L., and C. Scoglio,
"Label Switched Path (LSP) Preemption Policies for MPLS
Traffic Engineering", RFC 4829, April 2007.
Authors' Addresses
Matthew R. Meyer (editor)
British Telecom
Email: mrminc@gmail.com
JP Vasseur (editor)
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Meyer & Vasseur Expires March 5, 2009 [Page 13]
Internet-Draft draft-ietf-mpls-soft-preemption-12.txt September 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.
Meyer & Vasseur Expires March 5, 2009 [Page 14]
