One document matched: draft-lefaucheur-rsvp-dste-00.txt
Internet Draft Francois Le Faucheur
Michael Dibiasio
Bruce Davie
Cisco Systems, Inc.
Michael Davenport
Chris Christou
Booz Allen Hamilton
draft-lefaucheur-rsvp-dste-00.txt
Expires: January 2005 July 2004
Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels
Intellectual Property Rights (IPR) Statement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Status of this Memo
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document provides specification for aggregation of RSVP end-to-
end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS
Diffserv-aware MPLS Traffic Engineering (DS-TE) Tunnels. This
approach is based on RFC 3175 and simply modifies the corresponding
Le Faucheur, et al. [Page 1]
RSVP Aggregation over MPLS TE tunnels July 2004
procedures for operations over MPLS TE tunnels instead of aggregated
RSVP reservations. This approach can be used to achieve admission
control of a very large number of flows in a scalable manner since
the devices in the core of the network are unaware of the end-to-end
RSVP reservations and are only aware of the MPLS TE tunnels.
Specification of Requirements
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].
1.
Introduction
The Integrated Services (Intserv) [INT-SERV] architecture provides a
means for the delivery of end-to-end Quality of Service (QoS) to
applications over heterogeneous networks.
[RSVP] defines the Resource reSerVation Protocol which can be used by
applications to request resources from the network. The network
responds by explicitely admitting or rejecting these RSVP requests.
Certain applications that have quantifiable resource requirements
express these requirements using Intserv parameters as defined in the
appropriate Intserv service specifications ([GUARANTEED],
[CONTROLLED]).
The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was
then developed to support differentiated treatment of packets in very
large scale environments. In contrast to the per-flow orientation of
Intserv and RSVP, Diffserv networks classify packets into one of a
small number of aggregated flows or "classes", based on the Diffserv
codepoint (DSCP) in the packet's IP header. At each Diffserv router,
packets are subjected to a "per-hop behavior" (PHB), which is invoked
by the DSCP. The primary benefit of Diffserv is its scalability.
Diffserv eliminates the need for per-flow state and per-flow
processing and therefore scales well to large networks.
However, DiffServ does not include any mechanism for communication
between applications and the network. Thus, as detailed in [INT-
DIFF], significant benefits can be achieved by using Intserv over
Diffserv including resource based admission control, policy based
admission control, assistance in traffic identification
/classification and traffic conditioning. As discussed in [INT-DIFF],
Intserv can operate over Diffserv in multiple ways. For example, the
Diffserv region may be statically provisioned or may be RSVP aware.
When it is RSVP aware, several mechanisms may be used to support
dynamic provisioning and topology aware admission control including
Le Faucheur, et al. [Page 2]
RSVP Aggregation over MPLS TE tunnels July 2004
aggregated RSVP reservations, per flow RSVP or a bandwidth broker.
The advantage of using aggregated RSVP reservations is that it offers
dynamic, topology-aware admission control over the Diffserv region
without the scalability burden of per-flow reservations and the
associated level of RSVP signaling in the Diffserv core. [RSVP-AGGR]
describes in details how to perform such aggregation of end to end
RSVP reservations over aggregated RSVP reservations in a Diffserv
cloud. It establishes an architecture where multiple end-to-end RSVP
reservations sharing the same ingress router (Aggregator) and the
same egress router (Deaggregator) at the edges of an "aggregation
region", can be mapped onto a single aggregate reservation within the
aggregation region. This considerably reduces the amount of
reservation state that needs to be maintained by routers within the
aggregation region. Furthermore, traffic belonging to aggregate
reservations is classified in the data path purely using Diffserv
marking.
[MPLS-TE] describes how MPLS TE Tunnels can be established via [RSVP-
TE] and how these tunnels can be used to carry arbitrary aggregates
of traffic. MPLS TE uses Constraint Based Routing to compute the path
for a TE tunnel. Then, CAC (Call Admission Control) is performed
during the establishment of TE Tunnels to ensure they are granted
their requested resources.
[DSTE-REQ] presents the Service Providers requirements for support of
Diff-Serv-aware MPLS Traffic Engineering (DS-TE). With DS-TE,
separate DS-TE tunnels can be used to carry different Diffserv
classes of traffic and different resource constraints can be enforced
for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling
extensions as well as OSPF and ISIS extensions for support of DS-TE.
In the rest of this document we will refer to both TE tunnels and DS-
TE tunnels simply as "TE tunnels".
TE tunnels have much in common with the aggregate RSVP reservations
used in [RSVP-AGGR]:
- a TE tunnel is subject to CAC and thus is effectively an
aggregate bandwidth reservation
- In the data plane, packet scheduling relies exclusively on
Diff-Serv classification and PHBs
- Both TE tunnels and Aggregate RSVP reservations are controlled
by "intelligent" devices on the edge of the "aggregation core"
(Head-end and Tail-end in the case of TE tunnels, Aggregator
and Deaggregator in the case of Aggregated RSVP reservations
- Both TE tunnels and Aggregate RSVP reservations are signaled
using the RSVP protocol (with some extensions defined in [RSVP-
TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE
tunnels).
Le Faucheur, et al. [Page 3]
RSVP Aggregation over MPLS TE tunnels July 2004
This document provides a detailed specification for performing
aggregation of end-to-end RSVP reservations over aggregated RSVP
reservations which are instantiated as MPLS TE tunnels. This document
builds on the RSVP Aggregation procedures defined in [RSVP-AGGR], and
only changes those where necessary to operate over TE tunnels. With
[RSVP-AGGR], a lot of responsibilities (such as mapping end-to-end
reservations to Aggregate reservations and resizing the Aggregate
reservations) are assigned to the Deaggregator (which is the
equivalent of the Tunnel Tail-end) while with TE, the tunnels are
controlled by the Tunnel Head-end. Hence, the main change over the
RSVP Aggregations procedures defined in [RSVP-AGGR] is to modify
these procedures to reassign responsibilities from the Deaggregator
to the Aggregator (i.e. the tunnel Head-end).
Aggregation of end-to-end RSVP reservations over TE tunnels combines
the benefits of [RSVP-AGGR] with the benefits of MPLS including the
following:
- dynamic, topology-aware resource-based admission control can be
provided to applications over any segment of the end to end
path including the core
- as per regular RSVP behavior, RSVP does not impose any burden
on routers where such admission control is not needed (for
example if the links upstream and downstream of the MPLS TE
core are vastly over-engineered compared to the core capacity,
admission control is not required on these links and RSVP need
not be processed on the corresponding router hops)
- the core scalability is not affected (relative to the standard
MPLS TE deployment model) since the core remains unaware of
end-to-end RSVP reservations and only has to maintain aggregate
TE tunnels and since the datapath classification and scheduling
in the core relies purely on Diffserv mechanism (or more
precisely MPLS Diffserv mechanisms as specified in [DIFF-MPLS])
- the aggregate reservation (and thus the traffic from the
corresponding end to end reservations) can be network
engineered via the use of Constraint based routing (e.g.
affinity, optimization on different metrics) and when needed
can take advantage of resources on other paths than the
shortest path
- the aggregate reservations (and thus the traffic from the
corresponding end to end reservations) can be protected against
failure through the use of MPLS Fast Reroute
This document, like [RSVP-AGGR], covers aggregation of unicast
sessions. Aggregation of multicast sessions is for further study.
2.
Definitions
Le Faucheur, et al. [Page 4]
RSVP Aggregation over MPLS TE tunnels July 2004
For readability, a number of definitions from [RSVP-AGGR] as well as
definitions for commonly used MPLS TE terms are provided here:
Aggregator This is the router at the ingress edge of the
aggregation region (with respect to the end to end
RSVP reservation) and behaving in accordance with
[RSVP-AGG]. In this document, it is also the TE Tunnel
Head-end.
Deaggregator This is the router at the egress edge of the
aggregation region (with respect to the end to end
RSVP reservation) and behaving in accordance with
[RSVP-AGG]. In this document, it is also the TE Tunnel
Tail-end
E2E End to end
Head-end
This is the Label Switch Router responsible for
establishing, maintaining and tearing-off a given TE
tunnel.
Tail-end
This is the Label Switch Router responsible for
terminating a given TE tunnel
Transit LSR This is a Label Switch router which is on the path of
a given TE tunnel and is neither the Head-end nor the
Tail-end
3.
Operations of RSVP Aggregation over TE with pre-established Tunnels
[RSVP-AGG] supports operations both in the case where aggregate RSVP
reservations are pre-established and in the case where Aggregating
and De-aggregating routers have to dynamically discover each other
and dynamically establish the necessary Aggregated RSVP reservations.
Similarly, RSVP Aggregation over TE tunnels could operate both in the
case where the TE tunnels are pre-established and in the case where
the tunnels need to be dynamically established.
In this section we provide a detailed description of the procedures
in the case where TE tunnels are already established. Procedures in
the case of dynamically established TE tunnels will be provided in
later versions of this document.
3.1.
Reference Model
------ ------
H--I R I\ ------- -------- /I R I--H
Le Faucheur, et al. [Page 5]
RSVP Aggregation over MPLS TE tunnels July 2004
H--I I\\I I ----- I I//I I--H
-----I \I He/ I I T I I Te/ I/ ------
I Agg I=======================I Deag I
/I I I I I I\
H--------//I I ----- I I\\--------H
H--------/ ------- -------- \--------H
H = Host requesting end-to-end RSVP reservations
R = RSVP router
He/Agg = TE tunnel Head-end/Aggregator
Te/Deag = TE tunnel Tail-end/Deaggregator
T = Transit LSR
/ = E2E RSVP reservation
== = TE Tunnel
3.2.
Receipt of E2E Path message By the Aggregator
The first event is the arrival of the E2E Path message on the
Aggregator. Standard RSVP procedures are followed for this path
message (including update of the PHOP field to a local Aggregator
address) augmented with the extensions documented in this paragraph.
The Aggregator first attempts to map the E2E reservation onto a TE
tunnel. This decision is made in accordance with routing information
as well as any local policy information that may be available at the
Aggregator. Examples of such policies appear in the following
paragraphs.
There are situations where the Aggregator is able to make a final
mapping decision. That would be the case, for example, if there is a
single TE tunnel towards the destination and if the policy is to map
any E2E RSVP reservation onto TE Tunnels.
There are situations where the Aggregator is not able to make a final
determination. That would be the case, for example, if routing
identifies two DS-TE tunnels towards the destination, one belonging
to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to
map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel
and Intserv Controlled Load reservations to a Class-Type 0 tunnel,
and if the E2E RSVP Path message advertises both Guaranteed Service
and Controlled Load.
Whether final or tentative, the Aggregator makes a mapping decision
and selects a TE tunnel. Before forwarding the E2E Path message
towards the receiver, the Aggregator should update the ADSPEC inside
the E2E Path message to reflect the impact of the MPLS TE cloud onto
Le Faucheur, et al. [Page 6]
RSVP Aggregation over MPLS TE tunnels July 2004
the QoS achievable by the E2E flow. This update is a local matter and
may be based on configured information, on information available in
the MPLS TE topology database, on the current TE tunnel path, on
information collected via RSVP-TE signaling, or combinations of
those.
The Aggregator then forwards the E2E Path message inside the TE
tunnel. Because the E2E Path message is encapsulated inside the TE
tunnel, it will not be processed by Transit routers along the path of
the TE tunnel. Thus, in contrast to the procedures of [RSVP-AGGR],
the IP Protocol number need not be modified to "RSVP-E2E-IGNORE"; it
is left as is to "RSVP".
3.3.
Handling of E2E Path message By Transit LSRs
Since the E2E Path message is encapsulated inside the TE tunnel it is
hidden to all transit LSRs (except the Penultimate LSR when
Penultimate Hop Popping is used).
When Penultimate Hop Popping is used, the penultimate Router will pop
the tunnel label and, if no other label was imposed by the
Aggregator, the Path message will then be exposed. In this case, the
Penultimate Router must ignore the Path message. This may be ensured
via specific configuration of the Penultimate router.
3.4.
Receipt of E2E Path Message by Deaggregator
The Deaggregator will either receive the E2E Path message directly as
an IP packet (when the Aggregator did not impose any other label
below the tunnel label and Penultimate Hop popping is used) or will
expose the E2E Path message after popping (in all the other cases).
On detection of the Router Alert, the Deaggregator will detect and
process the E2E Path message and ultimately forward it towards the
receiver.
3.5.
Handling of E2E Resv Message by Deaggregator
Standard RSVP procedures are followed on receipt of the E2E Resv
message by the Deaggregator. This includes performing admission
control for the segment downstream of the Deaggregator and forwarding
the E2E Resv message to the PHOP signaled earlier in the E2E Path
message and which identifies the Aggregator.
3.6.
Handling of E2E Resv Message by the Aggregator
The Aggregator is responsible for ensuring that there is sufficient
bandwidth available and reserved over the appropriate TE tunnel to
the Deaggregator for the E2E reservation.
Le Faucheur, et al. [Page 7]
RSVP Aggregation over MPLS TE tunnels July 2004
On receipt of the E2E Resv message, the Aggregator first performs the
final mapping onto the final TE tunnels (if it was only a tentative
mapping). If needed the Aggregator updates the ADSPEC and immediately
generates an E2E Path refresh in order to provide the accurate ADSPEC
information to the receiver as soon as possible.
The aggregator then calculates the size of the resource request using
standard RSVP procedures. That is, it follows the procedures in
[RFC2205] to determine the resource requirements from the Sender
Tspec and the Flowspec contained in the Resv. It them compares the
resource requests with the available resources of the selected TE
tunnel.
If sufficient bandwidth is available on the final TE tunnel, the
Aggregator updates its internal understanding of how much of the TE
Tunnel is in use and forwards the E2E Resv messages to the
corresponding PHOP.
As noted in [RSVP-AGGR], a range of policies may be applied to the
re-sizing of the aggregate reservation (in this case, the TE tunnel.)
For example, the policy may be that the reserved bandwidth of the
tunnel can only be changed by configuration. More dynamic policies
are also possible, whereby the aggregator may attempt to increase the
reserved bandwidth of the tunnel in response to the amount of
allocated bandwidth that has been used by E2E reservations.
Furthermore, to avoid the delay associated with the increase of the
Tunnel size, the Aggregator may attempt to anticipate the increases
in demand and adjust the TE tunnel size ahead of actual needs by E2E
reservations.
If sufficient bandwidth is not available on the final TE Tunnel, the
Aggregator must follow the normal RSVP procedure for a reservation
being placed with insufficient bandwidth to support this reservation.
That is, the reservation is not installed and a ResvError is sent
back towards the receiver.
3.7.
Removal of E2E reservations
E2E reservations are removed in the usual way via PathTear, ResvTear,
timeout, or as the result of an error condition. When a reservation
is removed, the Aggregator updates its local view of the
resources available on the corresponding TE tunnel accordingly.
3.8.
Removal of TE Tunnel
Should a TE Tunnel go away (presumably due to a configuration change,
route change, or policy event), the aggregator behaves much like a
conventional RSVP router in the face of a link failure. That is, it
may try to forward the Path messages onto another tunnel, if routing
Le Faucheur, et al. [Page 8]
RSVP Aggregation over MPLS TE tunnels July 2004
and policy permit, or it may send Path_Error messages to the sender
if no suitable tunnel exists. In case the Path messages are forwarded
onto another tunnel which terminates on a different Deaggregator, or
the reservation is torn-down via Path Error messages, the reservation
state established on the router acting as the Deaggregator before the
TE tunnel went away, will time out since it will no longer be
refreshed.
3.9.
Example Signaling Flow
Aggregator Deaggregator
E2E Path
-------------->
(1)
E2E Path
===============================>
(2)
E2E Path
----------->
E2E Resv
<-----------
(3)
E2E Resv
<-----------------------------
(4)
E2E Resv
<-------------
(1) Aggregator tentatively selects the TE tunnel and forwards
E2E path inside TE Tunnel
(2) Deaggregator forwards the E2E Path towards receiver
(3) Deaggregator forwards the E2E Resv to the Aggregator
(4) Aggregator selects final TE tunnel, check there is
sufficient bandwidth on TE tunnel and forwards E2E Resv to
PHOP
4.
IPv4 and IPv6 Applicability
The procedures defined in this document are applicable to all the
following cases:
Le Faucheur, et al. [Page 9]
RSVP Aggregation over MPLS TE tunnels July 2004
(1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE
Tunnels
(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE
Tunnels
(3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE
tunnels, provided a mechanism such as [6PE] is used by the
Aggregator and Deaggregator for routing of IPv6 traffic over
an IPv4 MPLS core,
(4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE
tunnels, provided a mechanism is used by the Aggregator and
Deaggregator for routing IPv4 traffic over IPv6 MPLS.
5.
E2E Reservations Applicability
The procedures defined in this document are applicable to many types
of E2E RSVP reservations including the following cases:
(1) the E2E RSVP reservation is a per-flow reservation where the
flow is characterized by the usual 5-tuple
(2) the E2E reservation is an aggregate reservation for multiple
flows as described in [RSVP-AGG] where the set of flows is
characterized by the <source address, destination address,
DSCP>
(3) the E2E reservation is a reservation for an IPSec protected
flow. For example, where the flow is characterized by the
<source address, destination address, SPI> as described in
[RSVP-IPSEC]
(4) the E2E reservation is an aggregate reservation for multiple
flows and where the set of flows are protected by IPSec
(5) the E2E RSVP reservation is itself an RSVP-TE reservation
for an E2E TE tunnel, so that LSP Hierarchy is achieved
[LSP-HIER]
6.
Example Deployment Scenarios
6.1.
Voice and Video Reservations Scenario
An example application of the procedures specified in this document
is admission control of voice and video in environments with very
high numbers of hosts. In the example illustrated below, hosts
generate end-to-end per-flow reservations for each of their video
streams associated with a video-conference, each of their audio
streams associated with a video-conference and each of their voice
calls. These reservations are aggregated over MPLS DS-TE tunnels over
the packet core. The mapping policy defined by the user maybe that
all the reservations for audio and voice streams are mapped onto DS-
TE tunnels of Class-Type 1 while reservations for video streams are
mapped onto DS-TE tunnels of Class-Type 0.
Le Faucheur, et al. [Page 10]
RSVP Aggregation over MPLS TE tunnels July 2004
------ ------
I H I# ------- -------- #I H I
I I\#I I ----- I I#/I I
-----I \I Agg I I T I I Deag I/ ------
I I==========================I I
------ /I I::::::::::I I:::::::::::I I\ ------
I H I/#I I ----- I I#\I H I
I I# ------- -------- #I I
------ ------
H = Host
Agg = Aggregator (TE Tunnel Head-end)
Deagg = Deaggregator (TE Tunnel Tail-end)
T = Transit LSR
/ = E2E RSVP reservation for a Voice flow
# = E2E RSVP reservation for a Video flow
== = DS-TE Tunnel from Class-Type 1
:: = DS-TE Tunnel from Class-Type 0
6.2.
PSTN/3G Voice Trunking Scenario
An example application of the procedures specified in this document
is voice call admission control in large scale telephony trunking
environments. A Trunk VoIP Gateway may generate one aggregate RSVP
reservation for all the calls in place towards another given remote
Trunk VoIP Gateway (with resizing of this aggregate reservation in a
step function depending on current number of calls). In turn, these
reservations may be aggregated over MPLS TE tunnels over the packet
core so that tunnel Head-ends act as Aggregators and perform
admission control of Trunk Gateway reservations into MPLS TE Tunnels.
The MPLS TE tunnels may be protected by MPLS Fast Reroute.
This scenario is illustrated below:
------ ------
I GW I\ ------- -------- /I GW I
I I\\I I ----- I I//I I
-----I \I Agg I I T I I Deag I/ ------
I I==========================I I
------ /I I I I I I\ ------
I GW I//I I ----- I I\\I GW I
I I/ ------- -------- \I I
------ ------
GW = VoIP Gateway
Agg = Aggregator (TE Tunnel Head-end)
Deagg = Deaggregator (TE Tunnel Tail-end)
Le Faucheur, et al. [Page 11]
RSVP Aggregation over MPLS TE tunnels July 2004
T = Transit LSR
/ = Aggregate Gateway to Gateway E2E RSVP reservation
== = TE Tunnel
7.
Security Considerations
The security issues inherent to the use of RSVP, RSVP Aggregation and
MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP-
AGG] and [RSVP-TE].
In addition, in the case where the Aggregators dynamically resize the
TE tunnels based on the current level of reservation, there are risks
that the TE tunnels used for RSVP aggregation hog resources in the
core which could prevent other TE Tunnels from being established.
There are also potential risks that such resizing results in
significant computation and signaling as well as churn on tunnel
paths. Such risks can be mitigated by configuration options allowing
control of TE tunnel dynamic resizing (maximum Te tunnel size,
maximum resizing frequency,...) and/or possibly by the use of TE
preemption.
8.
Acknowledgments
This document builds on the [RSVP-AGGR] and [RSVP-TUN]
specifications.
9.
Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC2119, March 1997.
RFC 3668 S. Bradner, Intellectual Property Rights in IETF
Technology, RFC 3668, February 2004.
BCP 78, S. Bradner, IETF Rights in Contributions, RFC 3667, February
2004.
[INT-SERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, June 1994.
[GUARANTEED] Shenker et al., Specification of Guaranteed Quality of
Service, RFC2212
[CONTROLLED] Wroclawski, Specification of the Controlled-Load Network
Element Service, RFC2211
Le Faucheur, et al. [Page 12]
RSVP Aggregation over MPLS TE tunnels July 2004
[DIFFSERV] Blake et al., "An Architecture for Differentiated
Services", RFC 2475
[INT-DIFF] A Framework for Integrated Services Operation over
Diffserv Networks, RFC 2998, November 2000.
[RSVP-AGGR] Baker et al, Aggregation of RSVP for IPv4 and IPv6
Reservations, RFC 3175, September 2001.
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-07.txt,
February 2003.
[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-
proto-04.txt, June 2003
10.
Informative References
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270,
May 2002.
[6PE] De Clercq et al, "Connecting IPv6 Islands over IPv4 MPLS using
IPv6 Provider Edge Routers (6PE)", work in progress
[LSP-HIER] Kompella et al, "LSP Hierarchy with Generalized MPLS TE",
work in progress
[RSVP-IPSEC] Berger et al, "RSVP Extensions for IPSEC Data Flows",
RFC 2207
[RSVP-TUN] Terzis et al. "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000
11.
Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
Le Faucheur, et al. [Page 13]
RSVP Aggregation over MPLS TE tunnels July 2004
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.
12.
Authors Address:
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot Sophia-Antipolis
France
Email: flefauch@cisco.com
Michael DiBiasio
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Email: dibiasio@cisco.com
Bruce Davie
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Email: bdavie@cisco.com
Christou Christou
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
Michael Davenport
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
Le Faucheur, et al. [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 09:27:22 |