TSVWG F. Le Faucheur
Internet-Draft B. Davie
Expires: January 2, 2006 Cisco Systems
P. Bose
Lockheed Martin
C. Christou
M. Davenport
Booz Allen Hamilton
July 1, 2005
Generic Aggregate RSVP Reservations
draft-lefaucheur-rsvp-ipsec-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
[RSVP-IPSEC] defines RSVP extensions for IPSec which permit support
of reservations for individual IPsec flows, but it does not support
aggregate reservations between the IPSec devices with Diffserv
Le Faucheur, et al. Expires January 2, 2006 [Page 1]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
[DIFFSERV] classification and scheduling. Conversely, [RSVP-AGG]
defines how to aggregate individual RSVP reservations over Aggregate
IP reservations when the aggregation region supports Diffserv, but it
does not address the case where the aggregator and deaggregator use
IPSec . Also, [RSVG-AGG] does not address the case where multiple
Aggregate reservations are needed for the same DSCP from the same
Aggregator to the same Deaggregator. However, there are scenarios
requiring aggregate reservations for IPsec tunnels or requiring
multiple aggregate reservations for the same DSCP from a given
Aggregator to a given Deaggregator. This document specifies the
incremental RSVP extensions beyond those defined in [RSVP-IPSEC] and
[RSVP-AGG] to support such reservations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Aggregate Reservations For IPsec Tunnels . . . . . . . . . 4
1.2 Multiple Reservations Per DSCP From A Given Aggregator
To A Given Deaggregator . . . . . . . . . . . . . . . . . 6
1.3 Related RFCs and Internet-Drafts . . . . . . . . . . . . . 7
1.4 Organisation Of This Document . . . . . . . . . . . . . . 7
1.5 Change History . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Changes From -00 To -01 . . . . . . . . . . . . . . . 8
2. Overview of Extensions . . . . . . . . . . . . . . . . . . . . 9
3. Object Definition . . . . . . . . . . . . . . . . . . . . . . 11
3.1 SESSION Class . . . . . . . . . . . . . . . . . . . . . . 11
3.2 AGGREGATION-SESSION Class . . . . . . . . . . . . . . . . 11
4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Required Changes to Path and Resv Processing . . . . . . . 13
4.2 Required Changes to Aggregator/Deaggregator Processing . . 15
4.3 Merging Rules . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 FF and SE Styles . . . . . . . . . . . . . . . . . . . 16
4.3.2 WF Styles . . . . . . . . . . . . . . . . . . . . . . 16
5. Example Usages . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Example Usage Of Generic Aggregate Reservations in
Nested VPNs . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Example Usage Of Multiple Generic Aggregate
Reservations Per DSCP From a Given Aggregator to a
Given Deaggregator . . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
Le Faucheur, et al. Expires January 2, 2006 [Page 2]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1 Normative References . . . . . . . . . . . . . . . . . . . 28
9.2 Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 31
Le Faucheur, et al. Expires January 2, 2006 [Page 3]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
1. Introduction
[RSVP-IPSEC] defines RSVP extensions for IPSec which permit support
of reservations for individual IPsec flows, but it does not support
aggregate reservations between the IPSec devices with Diffserv
[DIFFSERV] classification and scheduling. Conversely, [RSVP-AGG]
defines how to aggregate individual RSVP reservations over Aggregate
IP reservations when the aggregation region supports Diffserv, but it
does not address the case where the aggregator and deaggregator use
IPSec . Also, [RSVG-AGG] does not address the case where multiple
Aggregate reservations are needed for the same DSCP from the same
Aggregator to the same Deaggregator. However, there are scenarios
requiring aggregate reservations for IPsec tunnels or requiring
multiple aggregate reservations for the same DSCP from a given
Aggregator to a given Deaggregator. This document specifies the
incremental RSVP extensions beyond those defined in [RSVP-IPSEC] and
[RSVP-AGG] to support such reservations.
1.1 Aggregate Reservations For IPsec Tunnels
Let us consider an environment as depicted in Figure 1. Let us
assume that the IPsec-Routers tunnel traffic to each other via IPSec
and that the devices within Cloud-1, Cloud-2 and Cloud-3 want to
establish RSVP reservations with one another transparently over the
IPSec Tunnels. Let us also assume that Cloud-0 supports Diffserv
(and not per-flow classification -except perhaps at the edge for
policing purposes) and that there is a need to reserve resources over
Cloud-0 to achieve the targeted levels of QoS assurance. Then there
is a need to establish aggregate reservations within Cloud-0 for the
IPsec tunnels transiting through Cloud-0. These aggregate
reservations will be used to aggregate the end-to-end RSVP
reservations between Cloud-1/2/3. This document concerns itself with
establishment of such aggregate reservations for IPSec tunnels.
The reader is referred to [SIG-NESTED] for a description of a more
generic nested VPN environment and for discussion and examples of QoS
signaling in that environment.
Le Faucheur, et al. Expires January 2, 2006 [Page 4]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
IPSec-Router-1 IPSec-Router-2
/ /
I----------I
I I
I Cloud-0 I
I I
I----------I
/
IPSec-Router-3
|
I----------I
I Cloud-3 I
I----------I
Figure 1: Example Scenario Requiring Aggregate Reservations for IPsec
tunnels
[RSVP-AGG] defines a Session Object containing only the deaggregator
IP address and the DSCP, and defines a Filter Spec Object containing
only the aggregator IP address. Thus, we observe that it is not
possible to convey the IPSec Security Parameter Index (SPI) that is
used for a given IPsec tunnel (unlike with [RSVP-IPSEC]). In turn,
this means that, if [RSVP-AGG] was used to establish aggregate
reservations for IPSec tunnels, it would not be possible for the
(edge) routers within Cloud-0 to classify traffic belonging to the
reservation corresponding to a given IPsec tunnel (say for the
purpose of doing policing on the edge of Cloud-0) . It also means
that it would not be possible (short of multiplying IP addresses) to
setup separate reservations for different IPsec tunnels (using
different SPIs) between the same IPsec encryptor and decryptor (which
may be used if different types of traffic have different security
requirements). Similarly, it would not be possible to set up
separate reservations for traffic going over the IPsec tunnel and for
traffic which is not encrypted (which is a useful scenario if some
traffic has IPSec requirement while the rest doesn't). Moreover, it
would not be possible to setup multiple reservations between a given
pair of IPsec encryptor and decryptor for transport of flows with
different preemptions [RSVP-PREEMP]. These restrictions illustrate
why the RSVP extensions defined in [RSVP-AGG] are not sufficient to
support aggregate reservations for IPSec tunnels.
[RSVP-IPSEC] defines a Session Object containing several fields
including a Virtual Destination Port (VDstPort) which allows support
of a different reservation for each IPSec flow , or even of multiple
reservations for a given IPSec flow. However, (unlike with [RSVP-
Le Faucheur, et al. Expires January 2, 2006 [Page 5]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
AGG]), the RSVP extensions of [RSVP-IPSEC] do not allow to include in
the information which uniquely defines the reservation (i.e. the
Session and Filter Spec objects) the DSCP of the PHB to be used for
aggregate classification and scheduling of the corresponding traffic.
The extensions of [RSVP-IPSEC] essentially assume a per-flow
classification model. This is why the RSVP extensions defined in
[RSVP-IPSEC] are not sufficient either to support aggregate
reservations for IPsec tunnels.
This document defines incremental RSVP extensions which simply
combine the concepts introduced in [RSVP-IPSEC] and in [RSVP-AGG] so
their benefits can be obtained simultaneously hence allowing
aggregate reservations for IPsec tunnels with Diffserv classification
and scheduling.
These extensions can be used in a number of scenarios. They allow
aggregation of end-to-end RSVP reservations over aggregate
reservations for IPsec tunnels. They also allow multi-level
aggregation for example whereby the end-to-end RSVP reservations are
first aggregated by a router acting as an [RSVP-AGG] aggregator and
then where the [RSVP-AGG] aggregate reservations are in turn
aggregated by the IPsec encryptor into "aggregate reservations for
IPsec tunnels" as specified in this document. They may also be used
to establish an aggregate reservation for an IPsec tunnel between an
IPsec encryptor and an IPsec decryptor for transport of other traffic
than the one corresponding to end to end RSVP reservations (for
example to provide a fixed pipe of Diffserv bandwidth from IPsec
encryptor to IPsec decryptor to carry end-to-end Diffserv traffic).
Another possible example usage is for establishment of an aggregate
reservation end-to-end from an IPsec end-system to another IPsec end-
system.
These extensions allow full support of QoS signaling in Nested VPNs
as discussed in [SIG-NESTED]. Example usage of these extensions in
Nested VPN is described in section 5.
1.2 Multiple Reservations Per DSCP From A Given Aggregator To A Given
Deaggregator
Let us consider an environment as described in [RSVP-AGG]. Now
imagine that different E2E RSVP reservations (corresponding to the
same DSCP) are established with different preemptions [RSVP-PREEMP]
and that the corresponding preemption need to be enforced over the
aggregation region. One method to achieve this is to establish one
Aggregate RSVP reservation per preemption level (actually used) for a
given DSCP and from a given Aggregator to a given Deaggregator.
Le Faucheur, et al. Expires January 2, 2006 [Page 6]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
As mentioned earlier, [RSVP-AGG] defines a Session Object containing
only the deaggregator IP address and the DSCP, and defines a Filter
Spec Object containing only the aggregator IP address. Thus, the
extensions defined in [RSVP-AGG] do not allow establishment of
multiple Aggregate RSVP reservations for a given <Aggregator/
Deaggregator/DSCP> Tuple (short of multiplying the IP addresses
allocated to the Aggregator or Deaggregator).
The extensions defined in this document combine the concept of
Virtual Destination Port introduced in [RSVP-IPSEC] which allow
establishment of multiple reservations between same source/
destination (when port numbers can not be used as a mechanim for
demultiplexing as is the case when IPsec is used) with the concepts
introduced in [RSVP-AGG]. This allows establishment of multiple
Aggregate RSVP reservations for a given <Aggregator/Deaggregator/
DSCP> Tuple.
1.3 Related RFCs and Internet-Drafts
The mechanisms defined in [BW-REDUC] (allowing an existing
reservation to be reduced in allocated bandwidth in lieu of tearing
that reservation down) are applicable to the aggregate reservations
for IPsec tunnels defined in the present document.
RSVP-TUNNEL] describes a general approach to running RSVP over
various types of tunnels. One of the types of tunnel, referred to as
a "type 2 tunnel", is similar to the tunnels described in this draft,
in that a single, aggregate reservation is made for the tunnel while
many individual flows are carried over that tunnel. However, [RSVP-
TUNNEL] does not address the case where data flows are encrypted, and
thus does not deal with the use of the SPI to identify flows and
sessions. Nor does it address the use of Diffserv-based
classification and queueing in the core of a network (between tunnel
endpoints), but rather relies on a UDP/IP tunnel header for
classification. Thus we require some additional objects and
procedures, defined in this draft, beyond those of [RSVP-TUNNEL].
1.4 Organisation Of This Document
Section 2 presents an overview of the RSVP extensions defined in this
document and how those are used. Section 3 provides specification
for the new RSVP objects. The changes to existing RSVP processing
rules are identified in Section 4. Section 5 provides example usages
of aggregate reservations for IPsec tunnels in a Nested VPN
environment as well as of aggregate IP reservations. The IANA
Considerations and the Security Considerations are discussed in
Section 6 and 7, respectively.
Le Faucheur, et al. Expires January 2, 2006 [Page 7]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
1.5 Change History
1.5.1 Changes From -00 To -01
The most significant change is the broadening of the applicability of
the new type of aggregate reservations beyond use for Aggregate
reservations for IPsec tunnels (to environments where IPsec is not
used). This affects the document in multiple places inclduing the
following changes:
o document renamed to "Generic Aggregate RSVP Reservations"
o added a subsection in Introduction to discuss a case where Generic
Aggregate RSVP Reservations are needed in non IPsec environments
o added text about the fact that the Generic Aggregate Reservations
can be used with IP-in-IP and GRE encapsultaion (in addition to
with Ipsec AH and ESP
o added example usage under Section 5 for environment where IPsec is
not used
The other significant changes are:
o added a subsection on the changes of the [RSVP-AGG] procedures
under Section 4
o added explanation about allocation of VDstPort values by
Deaggregator, in that same subsection
o added value of Protocol ID in all example generic aggregate
reservations in Section 5
Le Faucheur, et al. Expires January 2, 2006 [Page 8]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
2. Overview of Extensions
The extensions defined in this document can be seen as simply the
combination of the RSVP extensions defined in [RSVP-IPSEC] and in
[RSVP-AGG].
The basic notion of [RSVP-IPSEC] is to extend RSVP to use the IPSEC
Security Parameter Index (SPI) in place of the UDP/TCP-like ports.
This was achieved via:
o definition of a new FILTER_SPEC object which includes a
Generalized Port Identifier (GPI) field which is used to convey
the SPI
o definition of a new SESSION object which includes a Virtual
Destination Port (VDstPort). The VDstPort effectively allows for
the differentiation of multiple IPSec sessions destined to the
same IP address. (The VDstPort is used in the Session rather than
the SPI because it isn't feasible to force all senders to a
session to use the same SPI - which is needed in situations where
sharing of reservations across multiple senders is required)
One of the key notions of [RSVP-AGG] is that inside the aggregation
region, some RSVP reservation state is maintained per aggregate
reservation, while classification and scheduling state (e.g., DSCPs
used for classifying traffic) is maintained on a more highly
aggregated basis. For example, if Guaranteed Service reservations
are mapped to the EF DSCP throughout the aggregation region, there
may be a reservation for each aggregator/deaggregator pair in each
router, but only the EF DSCP needs to be inspected for classification
of the data traffic at each interior interface, and only a single
queue is used for all EF traffic. Support for this in [RSVP-AGG]
involved:
o definition of a new SESSION object which includes the DSCP
Hence, in order to simultaneously achieve support of per IPSec flow
reservations as well as Diffserv aggregate classification and
scheduling, this document :
o reuses the FILTER_SPEC object defined in [RSVP-IPSEC] and
containing a GPI (which in turn can include the SPI)
o defines a new SESSION object which contains both the VDstPort and
the DSCP
The use of the VDstPort field is as specified in [RSVP-IPSEC]. When
traffic from the E2E reservations is transported in aggregate IPsec
Le Faucheur, et al. Expires January 2, 2006 [Page 9]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
tunnels using AH or ESP, the use of the GPI field is as specified in
[RSVP-IPSEC]. When traffic from the E2E reservations is transported
into aggregate IP reservations using IP-in-IP or GRE, the GPI field
is not used. In that case, the GPI is to be set to 0 by the sender
of teh RSVP message and to be ignored by the receiver of the RSVP
message. The use of the DSCP field is as specified in [RSVP-AGG].
Where these RSVP extensions are used to perform aggregation of RSVP
reservations over generic aggregate RSVP reservations, the
aggregation and deaggregation functions are as specified in [RSVP-
AGG] unless explicitly spelled out in the following paragraphs.
Like with [RSVP-AGG], it is the Deaggregator which is responsible for
mapping E2E reservations onto generic aggregate reservations. In
turn, this means the Deaggregator is responsible for requesting the
Aggregator to initiate establishment of a new generic aggregate
reservation when necessary and also for conveying to the Aggregator
information about which generic aggregate reservation a given flow
needs to be mapped onto.
Like with [RSVP-AGG], to request establishment of a generic aggregate
reservation, the Deaggregator sends an E2E PathErr message with an
error code of NEW-AGGREGATE-NEEDED. However, to provide all the
necessary information about the needed generic aggregate reservation,
this document extends the procedures of [RSVP-AGG] and allow the
Deaggregator to include in the E2E PathErr message a new object
called AGGREGATION-SESSION. This object contains all the information
describing the Session of the needed new generic aggregate
reservation, in order to convey those to the Aggregator.
This document also extends the procedures of [RSVP-AGG] to allow the
Deaggregator to include the new AGGREGATION-SESSION object in the E2E
Resv message, in order to convey to the Aggregator which generic
aggregate session to map a given E2E reservation onto.
Le Faucheur, et al. Expires January 2, 2006 [Page 10]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
3. Object Definition
This document defines two new objects under the SESSION Class and a
new object under a new AGGREGATION SESSION Class.
It reuses the IPv4/GPI FILTER_SPEC, IPv6/GPI FILTER_SPEC, IPv4/GPI
SENDER_TEMPLATE and IPv6/GPI SENDER_TEMPLATE objects defined in
[RSVP-IPSEC].
3.1 SESSION Class
o AGGREGATE-IPv4/GPI SESSION object:
Class = 1
C-Type = To be allocated by IANA
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Protocol ID | Flags | vDstPort | DSCP |
+-------------+-------------+-------------+--+----------+
0 7 8 15 16 25 26 31
o AGGREGATE-IPv6/GPI SESSION object:
Class = 1
C-Type = To be allocated by IANA
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+--+----------+
| Protocol ID | Flags | vDstPort | DSCP |
+-------------+-------------+-------------+--+----------+
0 7 8 15 16 25 26 31
3.2 AGGREGATION-SESSION Class
Le Faucheur, et al. Expires January 2, 2006 [Page 11]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
o AGGREGATION-SESSION object:
Class = To be allocated by IANA
C-Type = To be allocated by IANA
0 7 8 15 16 25 26 31
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// SESSION Object //
| |
+-------------+-------------+-------------+-------------+
The Length, Class-Num and C-Type are those of the Session object
which is included inside the AGGREGATION-SESSION object. For
example, if the AGGREGATION-SESSION object is used to indicate that
the Aggregate Session needed is an AGGREGATE-IPv4/GPI SESSION then
the AGGREGATION-SESSION will be encoded like this:
0 7 8 15 16 25 26 31
+-------------+-------------+-------------+-------------+
| |AGGREGATE/GPI|AGGREGATE/GPI|
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Protocol ID | Flags | vDstPort | DSCP |
+-------------+-------------+-------------+--+----------+
0 7 8 15 16 25 26 31
Le Faucheur, et al. Expires January 2, 2006 [Page 12]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
4. Processing Rules
This section presents additions to the Processing Rules presented in
[RSVP-PROCESS] and in [RSVP-IPSEC]. These additions are required in
order to properly process the AGGREGATE-IPv4/GPI (resp AGGREGATE-
IPv6/GPI) SESSION object and the IPv4/GPI (resp. IPv4-6/GPI)
FILTER_SPEC object. Values for referenced error codes can be found
in [RSVP]. As with the other RSVP documents, values for internally
reported (API) errors are not defined.
When referring to the new AGGREGATE-IPv4/GPI and AGGREGATE-IPv6/GPI
SESSION objects, IP version will not be included and they will be
referred to simply as AGGREGATE/GPI SESSION, unless a specific
distinction between IPv4 and IPv6 is being made.
Similarly, as per the convention used in [RSVP-IPSEC], when referring
to the objects defined in [RSVP-IPSEC], IP version will not be
included unless a specific distinction between IPv4 and IPv6 is being
made.
4.1 Required Changes to Path and Resv Processing
Both RESV and PATH processing will need to be changed to support the
new objects.
The following PATH message processing changes are required:
o When a session is defined using the AGGREGATE/GPI SESSION object,
only the GPI SENDER_TEMPLATE may be used. When this condition is
violated, RSVP end-stations should report a "Conflicting C-Type"
API error to the application and routers should consider this as a
message formatting error.
o For PATH messages that contain the AGGREGATE/GPI SESSION object,
RSVP end-stations must verify that the protocol ID corresponds to
a protocol known to use the AGGREGATE/GPI SESSION object.
Protocol ID known to use the AGGREGATE/GPI SESSION are values 4
(IP-in-IP), 47 (GRE), 51 (AH) and 50 (ESP). If a router receives
such a Path message with a protocol ID which doesn't correspond to
a protocol known to use the AGGREGATE/GPI SESSION object, the
router should consider this as a message formatting error. If an
end-systems receives a Apth message with an unknown protocol ID,
then the API on the RSVP end-system should report an "API Error"
to the application.
o For PATH messages that contain the AGGREGATE/GPI SESSION object,
the VDstPort value and the DSCP value should be recorded. These
values form part of the recorded state of the session. Only the
Le Faucheur, et al. Expires January 2, 2006 [Page 13]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
DSCP need be passed to traffic control, since the vDstPort is not
contained in data packets.
The changes to RESV message processing are:
o When a RESV message contains a GPI FILTER_SPEC, the session must
be defined using either the GPI SESSION object (as per [RSVP-
IPSEC]) or the AGGREGATE/GPI SESSION object (as per this
document). Otherwise, this is a message formatting error.
o The GPI contained in the GPI FILTER_SPEC must match the GPI
contained in the SENDER_TEMPLATE. Otherwise, a "No sender
information for this Resv message" error is generated.
o When the GPI FILTER_SPEC is used and the SESSION type is
AGGREGATE/GPI, each node must have a data classifier installed for
the flow:
* If the node needs to perform fine-grain classification (for
example to perform fine-grain policing on ingress at a trust
boundary) then the node must create a data classifier described
by
+ the 5-tuple <DestAddress, protocol ID, SrcAddress, GPI,
DSCP> if the Protocol ID is AH or ESP. The data classifier
will need to look for the four byte GPI at transport header
offset +4 for AH, and at transport header offset +0 for ESP
(see [RSVP-IPSEC], [IPSEC-AG] and [IPSEC-ESP]). Note that
if multiple reservations are established with different
Virtual Destination Ports but with the same <DestAddress,
protocol ID, SrcAddress, GPI, DSCP>, then those cannot be
distinguished by the classifier. If the router is using the
classifier for policing purposes, the router will therefore
police those together and must program the policing rate to
the sum of th reserved rate across all the corrsponding
reservations.
+ the 4-tuple <DestAddress, protocol ID, SrcAddress, DSCP> if
the Protocol ID is IP-in-IP or GRE. Note that if multiple
reservations are established with different Virtual
Destination Ports but with the same <DestAddress, protocol
ID, SrcAddress, DSCP>, then those cannot be distinguished by
the classifier. If the router is using the classifier for
policing purposes, the router will therefore police those
together and must program the policing rate to the sum of th
reserved rate across all the corrsponding reservations.
Le Faucheur, et al. Expires January 2, 2006 [Page 14]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
* If the node only needs to perform Diffserv classification (for
example inside the aggregation domain downstream of the trust
boundary) then the node must rely on the Diffserv data
classifier based on the DSCP only.
4.2 Required Changes to Aggregator/Deaggregator Processing
As specified in [RSVP-AGG], the Deaggregator requests establishment
of the corresponding Aggregate Path by sending an E2E PathErr message
with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP
encoded in the respective DCLASS Object. However, this document
extends this procedure by allowing the Deaggregator to also include
in the E2E PathErr message an AGGREGATION-SESSION object which
contains the Session to be used for establishment of the Aggregate
Path. Note that this provides a very convenient mechanism to ensure
that different Aggregators use different sessions for their Aggregate
Path towards a given Deaggregator, because the Deaggregator can
easily select VDstPort numbers which are differenet for each
Aggregator and communicate those inside the AGGREGATION-SESSION
object. This provides an easy solution to establish separate
reservations from every Aggregator to a given Deaggregator.
Conversely, if reservation sharing was needed across multiple
Aggregators, the Deaggregator could facilitate this by allocating the
same VDstPort to the multiple Aggregators and thus including the same
AGGREGATION-SESSION object in the E2E PathErr messages sent to these
Aggregators so that they would establish Aggregate Path with the same
Session.
Similarly, the [RSVP-AGG] procedures for processing of an E2E PathErr
message by the Aggregator are extended so that the Aggregator uses
the Session provided in the AGGREGATION-SESSION object to establish
the Aggregate Path.
This document also extends the procedures of [RSVP-AGG] to allow the
Deaggregator to include the new AGGREGATION-SESSION object in the E2E
Resv message, in order to convey to the Aggregator which aggregate
session to map a given E2E reservation onto.
4.3 Merging Rules
When using the extensions defined in this draft, RSVP sessions are
defined by the 4-tuple: (DestAddress, protocol Id, vDstPort, DSCP).
Similarly, a sender is defined by the tuple: (SrcAddress, GPI) when
the protocol is AH or ESP, where the GPI field will be a four byte
representation of a generalized source port, or by the tuple
(SrcAddress) when the protocol is IP-in-IP or GRE . These extensions
have some ramifications depending upon the reservation style.
Le Faucheur, et al. Expires January 2, 2006 [Page 15]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
We note that VDstPorts can be communicated by Deaggregators to
Aggregators via the AGGREGATION-SESSION object included in the E2E
PathErr. This can be used to facilitate various sharing scenarios as
needed (e.g. the Deaggregator can convey the same VDstPort to
different Aggregators which need to share a reservation; or
conversely, the Deaggregator can communicate different VDstPorts to
different Aggregators which need to have separate reservations).
Policies followed by the Deaggregator to determine which aggregators
need shared or separate reservations are beyond the scope of this
document.
4.3.1 FF and SE Styles
In the FF and SE Styles, the FILTER_SPEC object contains the
(SrcAddress) or the (SrcAddress, SPI) pair. When the SPI is used,
this allows the receiver to uniquely identify senders based on both
elements of the pair. When merging explicit sender descriptors, the
senders may only be considered identical when both elements are
identical.
4.3.2 WF Styles
As with [RSVP-IPSEC], WF style is not well supported with these
extensions. Because there are no FILTER_SPEC objects for a WF
reservation, any data packets with the session's
Le Faucheur, et al. Expires January 2, 2006 [Page 16]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
5. Example Usages
5.1 Example Usage Of Generic Aggregate Reservations in Nested VPNs
/ \
( +--+ +--+ enclave ) ,---------.
.----------. \ |H2+---+R2| / ,-' `
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+
|H1+---+R1| \`. | ,' / |R3+---+H3|
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+
| / _.`---|VPN2||''-. \ |
enclave +----+-i.--'' +----++ `----.\ +----+ enclave
--------|VPN1|' | ``|VPN3| ,
,+----+ | +----+------'
,' --+-------+----------+------------------+---`.
,' ++-+ `.
,' |R7+--------+ `.
/ interface +--+ | \
domain 1 +-+--+ \
_.--------|VPN7|--------.
,-----'' +--+-+ `------. .
`-. ,-' | `-. .-'
`-: inner domain +-++ `.'
( |R9| )
.'. ++-+ ;-.
.' `-. | ,-' `-.
' `------. +-+--+ _.-----' `
interface `---------|VPN8|-------''
domain 2 +-+--+ /
\ | +--+ /
`. +----------+R8| ,'
`. ++-+ ,'
`. --+------------------+-----------+------+-- ,'
,-----+----+ | +----+------.
,' |VPN6|. | _.|VPN4| `
+----+.`----. +----+ _.--'' ,+----+
| \ `--=.-|VPN5|---:' / |
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+
|H6+---+R6| | ,' | `.| |R4+---+H4|
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+
// |H5+---+R5| \
enclave ,'( +--+ +--+ `. enclave
`. ,' \ enclave / '-. ,
`-------' \ / `-------'
Le Faucheur, et al. Expires January 2, 2006 [Page 17]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
Figure 2: Reservations in a Nested VPN
For clarity we will only consider a subset of the traffic flows and
will only consider:
o the flows from the VPN1 enclave to the VPN5 enclave (e.g. flows
from Host H1 to Host H5)
o the flows from the VPN2 enclave to the VPN5 enclave (e.g. flows
from Host H2 to Host H5)
Let us assume that:
o there is one security association between VPN1 and VPN5 (SPI1)
o there are two security associations between VPN2 and VPN5 (SPI2
and SPI3)
o the reservations from VPN1 enclave to VPN5 enclave have a
preemption P1
o the reservations from VPN2 enclave to VPN5 have a preemption of
either P1 or P2
o the reservations are either Voice (which needs to be treated in
the aggregation region using the EF PHB) or Video (which needs to
be treated in the aggregation region using the AF41 PHB)
o there is one security association between VPN7 and VPN8 (SPI4)
o that AH is used for IPsec tunneling
Then, the following generic aggregate RSVP reservations may be
established from VPN1 to VPN5 for aggregation of the lower level RSVP
reservations:
1. Reservation for aggregation of Voice reservations from VPN1
enclave to VPN5 enclave, requiring use of SPI1 and preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V1/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN1/SPI1
* POLICY_DATA (PREEMPTION_PRI)=P1
Le Faucheur, et al. Expires January 2, 2006 [Page 18]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
2. Reservation for aggregation of Video reservations from VPN1
enclave to VPN5 enclave, requiring use of SPI1 and preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V2/AF41
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN1/SPI1
* POLICY_DATA (PREEMPTION_PRI)=P1
where V1 and V2 are arbitrary VDstPort values picked by VPN5 within
the range set aside for dynamic allocation (see section 6).
The following generic aggregate RSVP reservations may be established
from VPN2 to VPN5 for aggregation of the lower level RSVP
reservations:
1. Reservation for aggregation of Voice reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI2 and preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V3/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN2/SPI2
* POLICY_DATA (PREEMPTION_PRI)=P1
2. Reservation for aggregation of Video reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI2 and preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V4/AF41
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN2/SPI2
* POLICY_DATA (PREEMPTION_PRI)=P1
3. Reservation for aggregation of Voice reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI2 and preemption P2:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V5/EF
* STYLE=FF or SE
Le Faucheur, et al. Expires January 2, 2006 [Page 19]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
* IPv4/GPI FILTER_SPEC=VPN2/SPI2
* POLICY_DATA (PREEMPTION_PRI)=P2
4. Reservation for aggregation of Video reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI2 and preemption P2:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V6/AF41
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN2/SPI2
* POLICY_DATA (PREEMPTION_PRI)=P2
5. Reservation for aggregation of Voice reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI3 and preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V7/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN2/SPI3
* POLICY_DATA (PREEMPTION_PRI)=P1
6. Reservation for aggregation of Video reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI3 and preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V8/AF41
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN2/SPI3
* POLICY_DATA (PREEMPTION_PRI)=P1
7. Reservation for aggregation of Voice reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI3 and preemption P2:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V9/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN2/SPI3
* POLICY_DATA (PREEMPTION_PRI)=P2
Le Faucheur, et al. Expires January 2, 2006 [Page 20]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
8. Reservation for aggregation of Video reservations from VPN2
enclave to VPN5 enclave, requiring use of SPI3 and preemption P2:
* AGGREGATE-IPv4/GPI SESSION=VPN5/AH/V10/AF41
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN2/SPI3
* POLICY_DATA (PREEMPTION_PRI)=P2
where V3 to V10 are arbitrary VDstPort values picked by VPN5 within
the range set aside for dynamic allocation (see section 6).
The following generic aggregate RSVP reservations may be established
from VPN7 to VPN8 for aggregation of the lower level RSVP
reservations (i.e. the reservations from VPN1 to VPN5 and from VPN2
to VPN5):
1. Reservation for aggregation of Voice reservations from interface
domain 1 to interface domain 2, requiring use of SPI4 and
preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN8/AH/V1/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN7/SPI4
* POLICY_DATA (PREEMPTION_PRI)=P1
2. Reservation for aggregation of Video reservations from interface
domain 1 to interface domain 2, requiring use of SPI4 and
preemption P1:
* AGGREGATE-IPv4/GPI SESSION=VPN8/AH/V2/AF41
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=VPN7/SPI4
* POLICY_DATA (PREEMPTION_PRI)=P1
5.2 Example Usage Of Multiple Generic Aggregate Reservations Per DSCP
From a Given Aggregator to a Given Deaggregator
Le Faucheur, et al. Expires January 2, 2006 [Page 21]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
Agg-Deag-1 Agg-Deag-2
/ /
I----------I
I I
I Cloud-0 I
I I
I----------I
/
Agg-Deag-3
|
I----------I
I Cloud-3 I
I----------I
Figure 3: Example Scenario Requiring Multiple Generic Aggregate IP
Reservations
Let us assume that:
o the E2E reservations from Cloud-1 to Cloud-3 have a preemption of
either P1 or P2
o the E2E reservations from Cloud-2 to Cloud-3 have a preemption of
either P1 or P2
o the E2E reservations are only for Voice (which needs to be treated
in the aggregation region using the EF PHB)
o traffic from the E2E reservations is encapsulated in Aggregate IP
reservations from Aggregator to Deaggregator using GRE
Then, the following generic aggregate RSVP reservations may be
established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end-
to-end RSVP reservations:
1. Reservation for aggregation of Voice reservations from Cloud-1 to
Cloud-3 requiring use of P1:
* AGGREGATE-IPv4/GPI SESSION=Agg-Deag-3/GRE/V1/EF
* STYLE=FF or SE
Le Faucheur, et al. Expires January 2, 2006 [Page 22]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
* IPv4/GPI FILTER_SPEC=Agg-Deag-1/0
* POLICY_DATA (PREEMPTION_PRI)=P1
2. Reservation for aggregation of Voice reservations from Cloud-1 to
Cloud-3 requiring use of P2:
* AGGREGATE-IPv4/GPI SESSION=Agg-Deag-3/GRE/V2/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=Agg-Deag-1/0
* POLICY_DATA (PREEMPTION_PRI)=P2
where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3
within the range set aside for dynamic allocation (see section 6).
And the following generic aggregate RSVP reservations may be
established from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-
to-end RSVP reservations:
1. Reservation for aggregation of Voice reservations from Cloud-2 to
Cloud-3 requiring use of P1:
* AGGREGATE-IPv4/GPI SESSION=Agg-Deag-3/GRE/V3/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=Agg-Deag-2/0
* POLICY_DATA (PREEMPTION_PRI)=P1
2. Reservation for aggregation of Voice reservations from Cloud-2 to
Cloud-3 requiring use of P2:
* AGGREGATE-IPv4/GPI SESSION=Agg-Deag-3/GRE/V4/EF
* STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=Agg-Deag-2/0
* POLICY_DATA (PREEMPTION_PRI)=P2
where V3 and V4 are arbitrary VDstPort values picked by Agg-Deag-3
within the range set aside for dynamic allocation (see section 6).
Le Faucheur, et al. Expires January 2, 2006 [Page 23]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
6. IANA Considerations
This document requests that IANA allocates two new C-Types under the
Class 1 for the two new RSVP objects defined in section 3.1.
This document requests that IANA allocates a new Class-Num and a new
C-Type for the two new RSVP object defined in section 3.2.
This document defines in section 3.1 a "Virtual Destination Port
(VDstPort)" field of 8 bits within the new Session objects defined in
this document. The range of possible vDstPort values is broken down
into sections, in a fashion similar to the VDstPort range of [RSVP-
IPSEC] (but not identical since the VDstPort field of [RSVP-IPSEC]
has 16 bits):
0 Illegal Value
1 - 63 Assigned by IANA
64 - 255 Dynamic
IANA is requested to create and maintain this new name space. The
IANA guidelines for assignments for this field are as follows: o
values in the range 1-63 are to be assigned according to the "XXX"
policy defined in [IANA-CONS].
Le Faucheur, et al. Expires January 2, 2006 [Page 24]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
7. Security Considerations
The mechanisms defined in [RSVP-CRYPTO] and [RSVP-CRYPTO2] can be
used to provide hop-by-hop integrity and authentication of RSVP
messages related to the aggregate reservations discussed in this
document.
The same considerations stated in [RSVP-IPSEC] and [SIG-NESTED] apply
to the extensions described in this document.
An additional data element, namely the DSCP is expressed in the
session object. The DSCP value of an associated flow should
correspond to the DSCP value in the session object. The requirements
of a router to aggregate a flow using DSCP are further described in
[RSVP-AGG] and [SIG-NESTED]. Protection against traffic analysis
attacks based on DSCP is outside the scope of the extensions in this
document. If an IPSec router uses a different IP address outside its
enclave from the one it uses within its enclave, the objects defined
or extended in this document should contain the external IP address
of the IPSec router. Example usage in Section 5 also depicts the
same preemption priority level being maintained through a nested
path. The policy preemption element may literally be the same as
used within the innermost VPN enclave or a different value as agreed
at VPN boundaries. The marking and remarking of priority levels
across administrative and VPN boundaries is beyond the scope of this
document. Protection against traffic analysis attacks based on
preemption is outside the scope of the extensions in this document.
Security concerns of message integrity, node and user authentication
are implicitly met by the security association that exists between
the IPSec/VPN routers.
Changes in SPI values for a given IPsec tunnel will affect associated
generic aggregate RSVP reservations. Changes will happen whenever
that IPsec tunnel changes its Security Association. Such changes
will occur when a tunnel is re-keyed (i.e. to use a new key). Re-
keying intervals are typically set based on traffic levels, key size,
threat environment,and crypto algorithm in use. When an SPI change
occurs it will, in most cases, be necessary to update (send) the
corresponding SENDER_TEMPLATEs and FILTER_SPECs. Implementations of
this specification need to take the possibility of changes of SPI
into account to ensure proper reservation behavior.
For those applications that do need to deal with changes of SPIs, the
impact of sending new PATH and RESV messages corresponding to
aggregate reservations will vary based on the reservation style being
used. Builders of such applications may want to select reservation
style based on interaction with SPI changes. The least impact of an
SPI change will be to WF style reservations. For such reservations,
Le Faucheur, et al. Expires January 2, 2006 [Page 25]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
a new SENDER_TEMPLATE will need to be sent, but no new RESV is
required. For SE style reservations, both a new SENDER_TEMPLATE and
a new RESV will need to be sent. This will result in changes to
state, but should not affect data packet delivery or actual resource
allocation in any way. The FF style will be impacted the most. Like
with SE, both PATH and RESV messages will need to be sent. But,
since FF style reservations result in sender receiving its own
resource allocation, resources will be allocated twice for a period
of time. Or, even worse, there won't be enough resources to support
the new flow without first freeing the old flow.
A way around this FF/SPI-change problem does exist. Applications
that want FF style reservations (in other words that want separate
reservations) can use multiple SE reservations. Each Aggregator
would have a separate SESSION definition thanks to a different
VDstPort value. This is facilitated by the ability of the
Deaggregator to distribute different VDstPorts to each Aggregator
(through the AGGREGATION-SESSION object in the E2E PathErr as
discussed above). When it came time to switch SPIs, a shared
reservation could be made for the new SPI while the old SPI was still
active. Once the new SPI was in use, the old reservation could be
torn down. This will provide uninterrupted service over the
aggregate reservations for IPsec tunnels.
Le Faucheur, et al. Expires January 2, 2006 [Page 26]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
8. Acknowledgments
This document borrows heavily from [RSVP-IPSEC] and [RSVP-AGG].
Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel
Voce and Anil Agarwal for their input into the content of this
document.
Le Faucheur, et al. Expires January 2, 2006 [Page 27]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
9. References
9.1 Normative References
[RSVP-IPSEC] "RSVP Extensions for IPSEC Data Flows", Berger et al,
RFC2207
[RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations",
Baker et al, RFC3175
[SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network",
Baker et al, draft-baker-tsvwg-vpn-signaled-preemption-02.txt
[RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1
Message Processing Rules", Braden et al, RFC2209
[IPSEC-AH] "IP Authentication Header", Kent et al, RFC2402
[IPSEC-ESP] "IP Encapsulating Security Payload (ESP)", Kent et al,
RFC2406
[RSVP-CRYPTO] "RSVP Cryptographic Authentication", Baker et al,
RFC2747
[RSVP-CRYPTO2] "RSVP Cryptographic Authentication", Braden et al,
RFC3097
9.2 Informative References
[BW-REDUC] "A Resource Reservation Extension for the Reduction of
Bandwidth of a Reservation Flow", Polk et al,
draft-polk-tsvwg-rsvp-bw-reduction-00.txt
[RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC
2746, January 2000.
Le Faucheur, et al. Expires January 2, 2006 [Page 28]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
Authors' Addresses
Francois Le Faucheur
Cisco Systems
Greenside - 400 Avenue de Roumanille
Sophia Antipolis, 06410
France
Phone: +33-4-97-23-26-19
Fax: +33-4-97-23-26-26
Email: flefauch@cisco.com
Bruce Davie
Cisco Systems
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone:
Fax:
Email: bdavie@cisco.com
Pratik Bose
Lockheed Martin
22300 Comsat Drive Clarksburg, MD 20814 USA
Phone: +1 301 428 4215
Fax: +1 301 428 5147
Email: pratik.bose@lmco. com
Chris Christou
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102,
USA
Phone:
Fax:
Email: christou_chris@bah.com
Le Faucheur, et al. Expires January 2, 2006 [Page 29]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
Mike Davenport
Booz Allen Hamilton
8283 Greensboro Drive McLean, VA 22102
USA
Phone:
Fax:
Email: davenport_michael@bah.com
Le Faucheur, et al. Expires January 2, 2006 [Page 30]
Internet-Draft Generic Aggregate RSVP Reservations July 2005
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Le Faucheur, et al. Expires January 2, 2006 [Page 31]
