One document matched: draft-davie-tsvwg-rsvp-l3vpn-00.txt
Network Working Group B. Davie
Internet-Draft F. le Faucheur
Intended status: Standards Track A. Narayanan
Expires: January 1, 2008 Cisco Systems, Inc.
June 30, 2007
Support for RSVP in Layer 3 VPNs
draft-davie-tsvwg-rsvp-l3vpn-00.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 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
RFC 4364 defines an approach to building provider-provisioned Layer 3
VPNs. It may be desirable to use RSVP to perform admission control
on the links between CE and PE routers. This document specifies
procedures by which RSVP messages travelling from CE to CE across an
L3VPN may be appropriately handled by PE routers so that admission
control can be performed on PE-CE links. Optionally, admission
control across the provider's backbone may also be supported.
Davie, et al. Expires January 1, 2008 [Page 1]
Internet-Draft RSVP for L3VPNs June 2007
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 6
3.1. Path Message Processing at Ingress PE . . . . . . . . . . 6
3.2. Path Message Processing at Egress PE . . . . . . . . . . . 8
3.3. Resv Processing at Egress PE . . . . . . . . . . . . . . . 9
3.4. Resv Processing at Ingress PE . . . . . . . . . . . . . . 9
3.5. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 9
4. Admission Control in Provider's Backbone . . . . . . . . . . . 10
5. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 11
5.1. VPN_Label Object . . . . . . . . . . . . . . . . . . . . . 11
5.2. VRF_ID Object . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Davie, et al. Expires January 1, 2008 [Page 2]
Internet-Draft RSVP for L3VPNs June 2007
1. Introduction
[RFC4364] defines a Layer 3 VPN service known as BGP/MPLS VPNs.
[RFC2205] defines the Resource Reservation Protocol (RSVP) which may
be used to perform admission control as part of the Integrated
Services (int-serv) architecture [RFC1633][RFC2210].
Customers of a layer 3 VPN service may run RSVP for the purposes of
admission control in their own networks. Since the links between
Provider Edge (PE) and Customer Edge (CE) routers in a layer 3 VPN
may often be resource constrained, it may be desirable to be able to
perform admission control over those links. In order to perform
admission control using RSVP in such an environment, it is necessary
that RSVP control messages, such as Path messages and Resv messages,
are appropriately handled by the PE routers. This presents a number
of challenges in the context of BGP/MPLS VPNs:
o RSVP Path message processing depends on routers recognizing the
router alert option in the IP header. However, packets traversing
the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the
router alert option is not normally visible to the egress PE.
o BGP/MPLS VPNs support non-unique addressing of customer networks.
Thus a PE at the ingress or egress of the provider backbone may be
called upon to process Path messages from different customer VPNs
with non-unique destination addresses.
o A PE at the ingress of the provider's backbone may receive Resv
messages corresponding to different customer VPNs from other PEs,
and needs to be able to associate those Resv messages with the
appropriate customer VPNs.
This document describes a set of procedures to overcome these
challenges and thus to enable admission control using RSVP over the
PE-CE links. We note that similar techniques may be applicable to
other protocols used for admission control such as NSIS [RFC4080].
Additionally, it may be desirable to perform admission control over
the provider's backbone on behalf of one or more L3VPN customers.
Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for
customer routes, and thus cannot natively process RSVP messages for
customer flows. Also the core is a shared resource that carries
traffic for many customers, so issues of resource allocation among
customers and trust (or lack thereof) must also be addressed. This
draft also specifies procedures for supporting such a scenario.
This draft deals with establishing reservations for unicast flows
only. Because the support of multicast traffic in BGP/MPLS VPNs is
Davie, et al. Expires January 1, 2008 [Page 3]
Internet-Draft RSVP for L3VPNs June 2007
still evolving, and raises additional challenges for admission
control, we leave the support of multicast flows for further study at
this point.
1.1. Terminology
This document draws freely on the terminology defined in [RFC2205]
and [RFC4364]. For convenience, we provide a few brief definitions
here:
o CE (Customer Edge) Router: Router at the edge of a customer site
that attaches to the network of the VPN provider.
o PE (Provider Edge) Router: Router at the edge of the service
provider's network that attaches to one or more customer sites.
o VPN Label: An MPLS label associated with a route to a customer
prefix in a VPN (also called a VPN route label).
o VRF: VPN Routing and Forwarding Table. A PE typically has
multiple VRFs, enabling it to be connected to CEs that are in
different VPNs.
2. Problem Statement
The problem space of this document is the support of admission
control between customer sites when the customer subscribes to a BGP/
MPLS VPN. We subdivide the problem into (a) the problem of admission
control on the PE-CE links (in both directions), and (b) the problem
of admission control across the provider's backbone.
For the PE-CE link subproblem, the most basic challenge is that RSVP
control messages contain IP addresses that are drawn from the
customer's address space, and PEs must be able to deal with traffic
from many customers who may have non-unique (or overlapping) address
spaces. Thus, it is essential that a PE be able in all cases to
identify the correct VPN context in which to process an RSVP control
message. Much of this draft deals with this issue.
For the case of making reservations across the provider backbone, we
observe that BGP/MPLS VPNs do not create any per-customer forwarding
state in the P (provider core) routers. Thus, in order to make
reservations on behalf of customer-specified flows, it is clearly
necessary to make some sort of aggregated reservation from PE-PE and
then map individual, customer-specific reservations onto an aggregate
reservation. That is similar to the problem tackled in [RFC3175] and
[RFC4804], with the additional complications of handling customer-
Davie, et al. Expires January 1, 2008 [Page 4]
Internet-Draft RSVP for L3VPNs June 2007
specific addressing associated with BGP/MPLS VPNs.
Finally, we note that RSVP Path messages are normally addressed to
the destination of a session, and contain the router alert IP option.
Routers along the path to the destination that are configured to
process RSVP messages must detect the presence of the router alert
option to allow them to intercept Path messages. However, the egress
PEs of a network supporting BGP/MPLS VPNs receive packets destined
for customer sites as MPLS-encapsulated packets, and normally forward
based only on examination of the MPLS label. Hence, a Path message
would typically be forwarded without examination of the IP options
and would therefore not receive appropriate processing at the PE.
This problem of recognizing and processing Path messages is also
discussed below.
2.1. Model of Operation
Figure 1 illustrates the basic model of operation with which this
document is concerned.
--------------------------
/ Provider \
|----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver
| |--| | |---| |---| | |---| |
|----| | | | P | | P | | | |----|
| PE1 |---| |-----| |-----| PE2 |
| | | | | | | |
| | |---| |---| | |
|-----| |-----|
| |
\ /
--------------------------
Figure 1. Model of Operation for RSVP-based admission control over
MPLS/BGP VPN
To establish a unidirectional reservation for a point-to-point flow
from Sender to Receiver that takes account of resource availability
on the CE-PE and PE-CE links only, the following steps must take
place:
1. Sender sends a Path message to an IP address of the Receiver.
2. Path message is processed by CE1 using normal RSVP procedures
and forwarded towards the Receiver along the link CE1-PE1.
Davie, et al. Expires January 1, 2008 [Page 5]
Internet-Draft RSVP for L3VPNs June 2007
3. PE1 processes Path message and forwards towards the Receiver
across the provider backbone.
4. PE2 processes Path message and forwards towards the Receiver
along link PE2-CE2.
5. CE2 processes Path message using normal RSVP procedures and
forwards towards Receiver.
6. Receiver sends Resv message to CE2.
7. CE2 sends Resv message to PE2.
8. PE2 processes Resv message (including performing admission
control on link PE2-CE2) and sends Resv to PE1.
9. PE1 processes Resv message and sends Resv to CE1.
10. CE1 processes Resv using normal RSVP procedures, performs
admission control on the link CE1-PE1 and sends Resv message to
Sender if successful.
In each of the steps involving Resv messages (6 through 10) the node
sending the Resv uses the previously established Path state to
determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to
that address. We note that establishing that Path state correctly at
PEs is one of the challenges posed by the BGP/MPLS environment.
3. Admission Control on PE-CE Links
In the following sections we trace through the steps outlined in
Section 2.1 and expand on the details for those steps where standard
RSVP procedures need to be extended or modified to support the BGP/
MPLS VPN environment. For all the remaining steps described in the
preceding section, standard RSVP processing rules apply.
3.1. Path Message Processing at Ingress PE
When a Path message arrives at the ingress PE (step 3 of Section 2.1)
the PE needs to establish suitable Path state and forward the Path
message on to the egress PE. In the following paragraphs we
described the steps taken by the ingress PE.
The Path message is addressed to the eventual destination (the
receiver at the remote customer site) and carries the IP Router Alert
option, in accordance with [RFC2205]. The ingress PE must recognize
the router alert, intercept these messages and process them as RSVP
Davie, et al. Expires January 1, 2008 [Page 6]
Internet-Draft RSVP for L3VPNs June 2007
signalling messages.
As noted above, there is an issue in recognizing Path messages as
they arrive at the egress PE (PE 2 in Figure 1). Since standard Path
messages carry the router alert IP option, one possible approach
would be to use the MPLS router alert label [RFC3032] when sending a
Path message from ingress PE to egress PE. However this may suffer
from problems of backwards compatibility with existing deployed
hardware that may not process the Router Alert label. The preferred
approach proposed here is to address the Path messages sent by the
ingress PE directly to the egress PE; that is, rather than using the
ultimate receiver's destination address as the destination address of
the Path message, we use the loopback address of the egress PE as the
destination address of the Path message. This approach has the
advantage that it does not require any new data plane capabilities
for the egress PE beyond those of a standard BGP/MPLS VPN PE.
Details of the processing of this message at the egress PE are
described below. The approach of addressing a Path message directly
to an RSVP next hop that is not the next IP hop is already used in
other environments such as those of [RFC4206] and [RFC4804].
The details of operation at the ingress PE are as follows. When the
ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is
addressed to the receiver, the VRF that is associated with the
incoming interface is identified, just as for normal data path
operations. The Path state for the session is stored, and is
associated with that VRF, so that potentially overlapping addresses
among different VPNs do not appear to belong to the same session.
The destination address of the receiver is looked up in the
appropriate VRF, and the BGP Next-Hop for that destination is
identified. That next-hop is the egress PE (PE2 in Figure 1). The
VPN label for that destination is obtained and placed in a new RSVP
object (VPN_LABEL, defined below.) A new Path message is constructed
with a destination address equal to the address of the egress PE
identified above. This new Path message will contain all the objects
from the original Path message, plus the VPN_LABEL object. Note that
the SESSION object contains the ultimate (customer) destination
address of the flow, while the IP header for the message contains the
address of the egress PE. In order to ensure that Resv messages that
will be sent to the ingress PE by the egress PE can be associated
with the correct VPN context, the Path message also needs to contain
an identifier that can be used to identify a VRF. The VRF_ID object
is defined below, and is used to carry a locally significant VRF
identifier. The VRF identifier needs to be meaningful only to the PE
that creates this object.
Davie, et al. Expires January 1, 2008 [Page 7]
Internet-Draft RSVP for L3VPNs June 2007
3.2. Path Message Processing at Egress PE
When a Path message arrives at the egress PE, it is addressed to the
PE itself, and is handed to RSVP for processing. The router needs to
a. Determine the egress VRF for this flow, and how to forward a Path
message on towards the correct CE and ultimate destination;
b. Store the information received in the Path message (including the
VRF_ID Object);
c. Construct a suitable Path message with the correct destination
address and forward it.
For step a, we can imagine the router containing an RSVP module and a
forwarding path module (this division is for exposition only; there
is no intention to specify the internal implementation here). The
RSVP module extracts the MPLS label contained in the VPN_LABEL
object, and the destination IP address contained in the SESSION
object, and passes them to the normal forwarding path code for MPLS-
encapsulated packets. The forwarding path returns to RSVP the
outgoing interface information, including the egress VRF, that would
have been used had a packet with that MPLS label and IP address been
received. (Note that in many cases the MPLS label alone is all that
is needed to determine the forwarding information for the packet, but
in some cases it is necessary to pop the label and examine the IP
address; hence both are passed to the forwarding code.)
Step b proceeds as follows. Note that [RFC2205] identifies the
fields in the SESSION object to define a session, specifically the
destination address, protocol and destination port. In this draft,
we can consider the identity of the egress VRF that was determined in
step a also to be part of the session definition. The identity of
this egress VRF is therefore stored with the Path state to facilitate
processing of Resv messages for this session.
Now the RSVP module can construct a Path message which differs from
the Path it received in the following ways:
a. Its destination address is the IP address extracted from the
SESSION Object;
b. It does not contain the VPN_LABEL Object or the VRF_ID Object.
c. The RSVP_HOP Object contains the IP address of the outgoing
interface of the egress PE and an LIH, as per normal RSVP
processing.
Davie, et al. Expires January 1, 2008 [Page 8]
Internet-Draft RSVP for L3VPNs June 2007
The router then sends the Path message on towards its destination
over the interface identified above.
3.3. Resv Processing at Egress PE
When a receiver at the customer site originates a Resv message for
the session, normal RSVP procedures apply until the Resv, making its
way back towards the sender, arrives at the "egress" PE (it is
"egress" with respect to the direction of data flow, i.e. PE2 in
figure 1). On arriving at PE2, the SESSION and FILTER objects in the
Resv, and the VRF in which the Resv was received, are used to find
the matching Path state stored previously. At this stage, admission
control can be performed on the PE-CE link.
Assuming admission control is successful, the PE constructs a Resv
message to send to the ingress PE (PE1 in Figure 1). It includes the
VRF_ID object that was obtained from the Path message as described
above. The Resv message is addressed to the ingress PE and sent.
If admission control is not successful, a ResvError message is sent
towards the receiver as per normal RSVP processing.
3.4. Resv Processing at Ingress PE
Upon receiving a Resv message at the ingress PE (with respect to data
flow, i.e. PE1 in Figure 1), the PE extracts the VRF identifier from
VRF_ID object and determines which VRF the session is associated
with. It is now possible to locate the appropriate Path state for
the reservation, and generate a Resv message to send to the
appropriate CE. Since we assume in this section that admission
control over the Provider's backbone is not needed, the ingress PE
does not perform any admission control for this reservation.
3.5. Other RSVP Messages
Processing of PathError, PathTear, ResvTear and ResvConfirm messages
is generally straightforward and follows the rules of [RFC2205].
However, for such messages going between the ingress and egress PEs,
two additional rules must be observed:
o The VRF_ID must be included in the message;
o The message must be directly addressed to the appropriate PE,
without using the IP Router Alert option.
Note that ResvError messages do not carry the Router Alert IP option,
and can be sent to the receiver as standard IP datagrams, and hence
no special processing other than normal VPN forwarding is needed at
Davie, et al. Expires January 1, 2008 [Page 9]
Internet-Draft RSVP for L3VPNs June 2007
the PEs for these messages.
Note: a future version of this draft will cover error cases in more
detail.
4. Admission Control in Provider's Backbone
The preceding section outlines how per-customer reservations can be
made over the PE-CE links. This may be sufficient in many situations
where the backbone is well engineered with ample capacity and there
is no need to perform any sort of admission control in the backbone.
However, in some cases, such as during failures or unanticipated
periods of overload, it may be desirable to be able to perform
admission control in the backbone on behalf of customer traffic.
Because of the fact that routes to customer addresses are not present
in the P routers, along with the concerns of scalability that would
arise if per-customer reservations were allowed in the P routers, it
is clearly necessary to map the per-customer reservations described
in the preceding section onto some sort of aggregate reservations.
Furthermore, customer data packets need to be tunneled across the
provider backbone just as in normal BGP/MPLS VPN operation.
Given these considerations, a feasible way to achieve the objective
of admission control in the backbone is to use the ideas described in
[RFC4804]. MPLS-TE tunnels can be established between PEs as a means
to perform aggregate admission control in the backbone.
An MPLS-TE tunnel from an ingress PE to an egress PE can be thought
of as a virtual link of a certain capacity. The main change to the
procedures described above is that when a Resv is received at the
ingress PE, an admission control decision can be performed by
checking whether sufficient capacity of that virtual link remains
available to admit the new customer reservation.
To achieve effective admission control in the backbone, there needs
to be some way to separate the data plane traffic that has a
reservation from that which does not. We assume that packets that
are subject to admission control on the core will be given a
particular MPLS EXP value, and that no other packets will be allowed
to enter the core with this value unless they have passed admission
control. Some fraction of link resources will be allocated to queues
on core links for packets bearing that EXP value, and the MPLS-TE
tunnels will use that resource pool to make their constraint-based
routing and admission control decisions. This is all consistent with
the principles of aggregate RSVP reservations described in [RFC3175].
Davie, et al. Expires January 1, 2008 [Page 10]
Internet-Draft RSVP for L3VPNs June 2007
5. Object Definitions
5.1. VPN_Label Object
The usage of the VPN_LABEL Object is described in Section 3.1 and
Section 3.2. The VPN_LABEL object should appear in all RSVP messages
that contain a SESSION object and are sent from ingress PE to egress
PE, with the exception of ResvError messages. (As noted above,
ResvError messages are sent as normal IP datagrams and not processed
at the egress PE by RSVP.) The object MUST NOT be included in any
RSVP messages that are sent outside of the provider's backbone. The
format of the object is as follows:
VPN_LABEL object: Class = TBA, C-Type = 1
+-------------+-------------+-------------+-------------+
| Reserved(12 bits) | Label (20 bits) |
+-------------+-------------+-------------+-------------+
The Reserved bits must be set to zero on transmission and ignored on
receipt.
5.2. VRF_ID Object
The usage of the VRF_ID Object is described in Section 3. The VRF_ID
object is a locally significant opaque value. The object is inserted
into RSVP messages that carry a SESSION object, and that travel
between the Ingress and Egress PEs with the exception of ResvError
messages. (As noted above, ResvError messages are sent as normal IP
datagrams and not processed at the egress PE by RSVP.) It MUST NOT
be included in any RSVP messages that are sent outside of the
provider's backbone. The format of the object is as follows:
VRF_ID object: Class = TBA, C-Type = 1
+-------------+-------------+-------------+-------------+
| VRF_ID (32 bits) |
+-------------+-------------+-------------+-------------+
6. IANA Considerations
This document requires IANA assignment of two new RSVP Class Numbers
to accommodate the new objects described in Section 5. These should
be assigned from the range 0x11bbbbbb, so that they will be ignored
but forwarded by routers that do not understand them.
Davie, et al. Expires January 1, 2008 [Page 11]
Internet-Draft RSVP for L3VPNs June 2007
7. Security Considerations
[RFC4364] addresses the security considerations of BGP/MPLS VPNs in
general. General RSVP security considerations are addressed in
[RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication
mechanisms defined in [RFC2747] and [RFC3097]may be used. These
protect RSVP message integrity hop-by-hop and provide node
authentication as well as replay protection, thereby protecting
against corruption and spoofing of RSVP messages. [Behringer]
discusses applicability of various keying approaches for RSVP
Authentication. We note that the RSVP signaling in MPLS VPN is
likely to spread over multiple administrative domains (e.g. the
service provider operating the VPN service, and the customers of the
service). Therefore the considerations in [Behringer] about inter-
domain issues are likely to apply.
Beyond those general issues, two specific issues are introduced by
this document: resource usage on PEs, and resource usage in the
provider backbone. We discuss these in turn.
A customer who makes resource reservations on the CE-PE links for his
sites is only competing for link resources with himself, as in
standard RSVP, at least in the common case where each CE-PE link is
dedicated to a single customer. Thus, from the perspective of the
CE-PE links, this draft does not introduce any new security issues.
However, because a PE typically serves multiple customers, there is
also the possibility that a customer might attempt to use excessive
computational resources on a PE (CPU cycles, memory etc.) by sending
large numbers of RSVP messages to a PE. In the extreme this could
represent a form of denial-of-service attack. In order to prevent
such an attack, a PE should have mechanisms to limit the fraction of
its processing resources that can be consumed by any one CE or by the
set of CEs of a given customer. For example, a PE might implement a
form of rate limiting on RSVP messages that it receives from each CE.
The second concern arises only when the service provider chooses to
offer resource reservation across the backbone, as described in
Section 4. In this case, the concern may be that a single customer
might attempt to reserve a large fraction of backbone capacity,
perhaps with a co-ordinated effort from several different CEs, thus
denying service to other customers using the same backbone.
[RFC4804] provides some guidance on the security issues when RSVP
reservations are aggregated onto MPLS tunnels, which are applicable
to the situation described here. We note that a provider may use
local policy to limit the amount of resources that can be reserved by
a given customer from a particular PE, and that a policy server could
be used to control the resource usage of a given customer across
multiple PEs if desired.
Davie, et al. Expires January 1, 2008 [Page 12]
Internet-Draft RSVP for L3VPNs June 2007
8. Acknowledgments
Thanks to Ashwini Dahiya, Prashant Srinivas and Manu Pathak for their
many contributions to solving the problems described in this draft.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels",
RFC 4804, February 2007.
9.2. Informative References
[Behringer]
Behringer, M. and F. le Faucheur, "A framework for RSVP
security using dynamic group keying", July 2007.
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt.
Work in Progress
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Davie, et al. Expires January 1, 2008 [Page 13]
Internet-Draft RSVP for L3VPNs June 2007
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007.
Authors' Addresses
Bruce Davie
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA 01719
USA
Email: bsd@cisco.com
Francois le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
Biot Sophia-Antipolis 06410
France
Email: flefauch@cisco.com
Davie, et al. Expires January 1, 2008 [Page 14]
Internet-Draft RSVP for L3VPNs June 2007
Ashok Narayanan
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA 01719
USA
Email: ashokn@cisco.com
Davie, et al. Expires January 1, 2008 [Page 15]
Internet-Draft RSVP for L3VPNs June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Davie, et al. Expires January 1, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-21 22:05:05 |