Internet DRAFT - draft-boucadair-pce-interas
draft-boucadair-pce-interas
PCE Working Group M. Boucadair (Ed.)
IETF Internet Draft P. Morand (Ed.)
Document: draft-boucadair-pce-interas-01.txt France Telecom R&D
Proposed Status: Informational May 2005
Expires: November 2005
A Solution for providing inter-AS MPLS-based QoS tunnels
< draft-boucadair-pce-interas-01.txt >
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667 [RFC3667]. 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 become aware will be disclosed, in
accordance with RFC 3668 [RFC3668].
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 November 2005.
Abstract
This document describes a solution for providing inter-AS MPLS-based
Quality of Service (QoS) tunnels. This solution makes use of Path
Computation Elements (PCE) as a means to compute inter-domain
constraint-based paths. Service considerations and agreements between
two IP Network Providers (INP) implementing this solution are also
described.
Copyright Notice
Boucadair (Ed.) Informational - Expires November 2005 [Page 1]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
Copyright (C) The Internet Society. (2005)
Table of Contents
1. Contributors................................................2
2. Changes since last version:.................................2
3. Terminology.................................................2
4. Introduction................................................3
4.1. General.....................................................3
4.2. Assumptions.................................................4
4.3. Draft structure.............................................5
5. Conventions used in this document...........................5
6. Inter-AS PCE model..........................................5
7. Inter-provider Service Considerations.......................7
8. Path Computation Element functions..........................8
9. PCE discovery..............................................10
10. PCE to PCE Communication...................................10
11. Routing considerations.....................................11
11.1. Assumptions.................................................11
11.2. Finding inter-domain LSP paths..............................11
12. Communication between PCE and LSR/LER for initiating
LSP set-up...............................................13
13. Advanced features..........................................13
13.1. Exclusion of specific ASs from the path.....................13
13.2. Feedback....................................................13
14. Security Considerations....................................14
15. References.................................................14
16. Acknowledgments............................................14
17. Author's Addresses.........................................15
1. Contributors
o Hamid Asgari (Thales Research and Technology)
o Noel Butler (Thales Research and Technology)
o Panagiotis Georgatsos (Algonet)
o David Griffin (University College London)
o Micheal Howarth (University of Surrey)
2. Changes since last version:
The main changes occurred in this version are:
o Add new contributor to the draft
o Rewording of several sections of the draft
3. Terminology
This memo makes use of the following terms:
Boucadair (Ed.) Informational - Expires November 2005 [Page 2]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
o Path Computation Element (PCE): an entity that is responsible
for computing/finding inter/intra domain MPLS tunnels (LSPs).
This entity can simultaneously act as client and a server.
Several PCEs can be deployed in a given AS.
o Path Computation Client (PCC): a PCE acting as a client. This
entity is responsible for issuing path computation requests that
fulfill the Service Management constraints for the establishment
of inter/intra domain LSPs.
o Path Computation Server (PCS): a PCE acting as a server. This
entity is responsible for handling path computation requests
including neighboring PCC constraints.
o High-level service: the service employing a PCE-based system as
the underlying infrastructure for creating e.g., inter-domain
QoS VPNs.
o High-level service customer: the customer that subscribes to a
High-level service.
o pSLS(provider SLS): A provider level SLS, which is established
for specific QoS class between two Internet Network Providers
(INP) for exchanging traffic in the Internet with the purpose to
expand the geographical span of their offered services. pSLSs
are meant to support aggregate traffic and they are assumed to
exist prior to any agreements with end customers.
o SLS Management: a service level management system, which
includes service ordering (i.e for establishing contracts
between peer providers) and service invocation (i.e for
committing resources before traffic can be admitted)
o q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into
account QoS information as input for its route selection
process.
o Domain: within this document it denotes an Autonomous System.
4. Introduction
4.1. General
The level of Quality of Service (QoS) guarantees offered by INPs
using a pure IP-based traffic engineering (TE) solution, other than
overbooking, is not yet satisfactory for all corporate business
services, for which strong guarantees must be provided. For this type
of customers, hard QoS performance and bandwidth guarantees are
considered as the major requirements.
Boucadair (Ed.) Informational - Expires November 2005 [Page 3]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
Currently, these requirements can be satisfied within a single domain
or across several interconnected domains managed only by a single
INP. However, it becomes very challenging when these domains are
managed by different INPs. Each INP defines and deploys its own QoS
policy within the scope of its domain(s), utilizes its proprietary TE
functions, etc.
Providing QoS-based services within the scope of the Internet
requires the collaboration among INPs in order to offer this type of
services. This document aims at proposing a solution that will
facilitate the introduction of such services in an Inter-provider
environment. Service considerations are also taken into account.
4.2. Assumptions
In this document, we assume the following:
o An AS can announce a given prefix in several QoS planes; each of
these QoS planes being identified across inter-domain links by a
unique DiffServ Code Point (DSCP);
o Each announcement, except best effort ones, contains values of a
set of QoS parameters that characterizes the likely end-to-end
QoS to be experienced for reaching a given prefix (we call this
end-to-end QoS as aggregated QoS);
o The way aggregated QoS values are computed is out of the scope
of this document;
o Adjacent ASs agree on the DSCP values to use in order to signal
a given QoS class at inter-domain links (we call these DSCP
values inter-domain DSCPs);
o Every AS has the freedom to bind an inter-domain DSCP to a local
DSCP within its domain, which identifies its local QoS class for
signalling a QoS planes in its domain;
o An AS supporting the inter-domain MPLS-based QoS tunnels
service, owns a Path Computation Service Identifier(s) (PCSID),
which is a routable IP address. This IP address is not
necessarily the IP address(es) of the PCE(s) of the domain.
These PCSIDs are announced per QoS plane basis, by an inter-
domain routing protocol, together with the planeÆs aggregated
QoS values;
o ASs can discover other ASs supporting the inter-domain MPLS-
based QoS tunnels service by receiving inter-domain routing
protocol announcements. These announcements provide an AS with
Boucadair (Ed.) Informational - Expires November 2005 [Page 4]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
the end-to-end QoS characteristics of the path towards any
prefix of the remote AS owning the PCSID.
4.3. Draft structure
The structure of this document is as follows:
o Section 5 describes the inter-AS PCE model.
o Section 6 discusses the service considerations.
o Section 7 highlights PCE functions.
o Section 8 explains the PCE discovery function.
o Section 9 gives an overview of the PCP protocol that is used for
communication between PCEs.
o Section 10 and 11 describe routing issues.
o Finally, section 12 presents some advance features in order to
enhance PCE service.
5. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
6. Inter-AS PCE model
A Path Computation Element (PCE) is responsible for finding an inter-
domain path satisfying a set of constraints (e.g. specific QoS
performance guarantees requested by a customer), in order to
establish inter-domain constraint-based LSPs.
In an inter-provider environment, the computation of this path is
necessarily distributed and required communication between PCEs of
different domains. Communication between PCE entities is achieved via
the PCE Communication Protocol (PCP, [INTERAS-PCP]). Once computed,
the path is provided to the RSVP-TE/MPLS machinery of the head-end
Label Switching Router (LSR), which can request/establish an inter-
domain Label Switching Path (LSP) that will follow the inter-domain
path provided by the PCE.
+----------------+
| |
+----+ AS1 +----+
Boucadair (Ed.) Informational - Expires November 2005 [Page 5]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
..........|ASBR| |ASBR|.......... BGP Session
. +----+ +----+ .
. | | .
. | +----+ | .
. +-----|PCE |-----+ .
. +----+ .
. ^ ^ .
. | | .
. | | .
+----+ | | +----+
+-----|ASBR|-----+ | | +-----|ASBR|-----+
| +----+ | | | | +----+ |
| AS2 +----+ | | +----+ AS3 |
| | P | | | | P | |
| | C |<---------/ \-------->| C | |
| | E |<--------------------->| E | |
| +----+ +----+ |
| | | |
| +----+ | | +----+ |
+-----|ASBR|-----+ +-----|ASBR|-----+
+----+ +----+
|. . . . . . . . . . . . . . . . . . . . . . . |
...: Peering links
---: inter-PCE session
Figure 1: Inter-AS PCE scenario
In the above figure, we assume that each domain operates a set of
QoS-classes. Each INP deploys its own local QoS-classes with specific
QoS characteristics. QoS-classes in a domain have not necessarily the
same QoS characteristics with QoS-classes in the other domains. We
also assume that service level QoS-based contracts (pSLSs) have been
established between adjacent domains. BGP is running between these
adjacent ASs. Each AS learns, the set of destinations its peer
domains can reach, together with end-to-end QoS performance
characteristics.
When a pSLS is established, the domains exchange their respective PCE
information (name, IP address, identifiers, authentication
information, etc.).
In order to create an inter-domain constraint-based LSP, the domain
which requests the establishment of the LSP asks its PCE to compute
an inter-domain path satisfying a set of constraints, (for example
bandwidth guarantee per QoS-Class, maximum end-to-end delay, etc.)
The first PCE selects one possible path among the set of alternatives
and identifies the next-hop domain. It then verifies that appropriate
resources are available in its own domain and sets up administrative
pre-reservations in the management system of its domain. Then it
Boucadair (Ed.) Informational - Expires November 2005 [Page 6]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
contacts the next hop PCE, requesting a path computation between the
next hop AS Border Router (ASBR) and the termination address of the
inter-domain LSP. This second PCE performs the same computation as
the first one did and the procedure is iteratively repeated up to the
last PCE. If a path satisfying all requirements is found, each PCE
returns the path received from the responding PCE concatenated with
the sub-path it computed. Finally, the originating PCE receives the
whole computed path.
7. Inter-provider Service Considerations
A pSLS MUST be established between two neighbors in order to grant to
the requestor the appropriate rights for requesting and/or
establishing inter-domain LSPs (see figure below). Nevertheless,
information like destination and number of future LSPs to be
established is not known in advance. The pSLS indicates only the
upper-boundaries that the upstream AS is allowed to use, in terms of
QoS-class identifiers that can be used at the inter-domain for
establishing inter-domain LSP and in terms of maximum bandwidth
associated to each QoS-class.
The pSLS agreement does not reserve any network resources in advance.
Resources are only allocated when an inter-domain LSP is set up. The
management plane of each downstream domain along the path SHOULD be
aware of the existence of those LSPs together with their associated
QoS guarantees.
+--------High Level Service Agreement--------+
| |
v v
<----AS1-----> <----AS2-----> <----AS3----->
' ' ' ' ' '
' '<-pSLS->' '<- pSLS->' '
' ' ' ' ' '
+------------+ +------------+ +------------+
| PCE | | PCE | | PCE |
| | | | | |
| +------+ | | +------+ | | +------+ |
| | PCC | | | | PCC | | | | PCC | |
| | |<-|--\ | | |<-|--\ | | | |
| +--/\--+ | | | +--/\--+ | | | +--/\--+ |
| || | |PCP | || | |PCP | || |
| || | | | || | | | || |
| +--\/--+ | | | +--\/--+ | | | +--\/--+ |
| | PCS | | \-----|->| PCS | | \------|->| PCS | |
| | | | | | | | | | | |
| +------+ | | +------+ | | +------+ |
+------------+ +------------+ +------------+
Figure 2: Service Overview
Boucadair (Ed.) Informational - Expires November 2005 [Page 7]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
However, it is difficult to establish such a contract in advance
especially when the LSP path is not known in advance. Thus, the
sequence of operation for establishing an LSP should be:
o Compute inter-domain path candidate(s);
o Select and request an inter-domain path for this particular LSP
using information returned by the PCE,
o Establish the LSP once final negotiation terms have been agreed
end-to-end between PCEs of adjacent domains.
The establishment of this cascade of negotiations can be difficult to
achieve and can take some time. In particular, the risk is not
negligible that the resources that were available when the PCE
performed the path computation are no longer available along the path
when the cascaded negotiation terms are agreed, because others LSPs
have used the corresponding resources.
In order to solve this issue it is necessary that the PCE of each
domain makes an administrative reservation of the corresponding
resources and indicates the characteristics of the path. This
information is registered by the management plane, which triggers in
parallel the creation of a provisional contract referencing the
technical characteristics of the future LSP. Subsequent path
computation requests may be impacted because the management plane
removes these resources from the available overall network resources.
This provisional contract is valid for a limited time period, which
is the minimum of time periods each specified and reported by a
domain along the path. If time period expires, the provisional
contract can be removed from the management systems, and related
administrative network resources have to be informed.
It is the responsibility of the management plane of each domain to
cooperate in agreeing the exact financial terms and additional
clauses of this contract, including its duration. Each domain knows
the entry and the exit point of the LSP within its own domain and
consequently knows both the upstream and downstream ASs to deal with.
This validation procedure SHOULD ideally be automated to speed up the
process and could integrate pricing negotiation. The way that the
other blocks of the management plane deal with this automation is out
the scope of this document.
Thus, once the pre-contract is validated, the path computed by the
PCE can be provided to the head-end LSP, which effectively sets up
the LSP. Note that every ingress point of each domain SHOULD activate
some outsourced policy functions that would allow RSVP TE to get an
agreement from the management system.
8. Path Computation Element functions
Boucadair (Ed.) Informational - Expires November 2005 [Page 8]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
The main function provided by a PCE is to contribute to the overall
path computation by computing part of the end-to-end inter-domain
path satisfying a set of constraints. The management plane could call
other elementary services such as requesting a path computation for
informational purposes or canceling a request in progress for
instance.
The deployment and the maintenance of the LSP connectivity require
cooperation of several functional entities from different planes.
Within this document, the PCE is only responsible for computing an
inter-domain constraint-based path. The implementation of the service
(whether it is automated or not) and the creation of inter-domain LSP
results from the cooperation of functional blocks, control plane
blocks and data plane blocks arenÆt described in this document.
The PCE does not itself trigger the establishment of any inter-domain
LSP, but provides inter-domain paths, if they are available. Unlike
the management plane, it is not aware of business considerations A
PCE entity provides an interface used by the service management block
to request a path computation. It communicates with other remote PCE
thanks to the PCP protocol and requests additional services from
other functional blocks as illustrated in the figure below:
+---------------------+
| Service Management |
+----------o----------+
|
|
v
+----------+ +----------+ +----------+
| PCE |<---------->| PCE |<---------->| PCE |
+----------+ +----------+ +----------+
|
/----------------+-----------------+----------------\
| | | |
+---v---+ +---v---+ +---v---+ +---v---+
| | | | | | | |
|BW Mgt | | SLS | |Access | | Intra |
| | | Mgt | | & | | & |
| | | | |Author | | Inter |
| | | | | | | TE |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
Figure 3: PCE Interactions
The PCE interacts with the dynamic routing processes to retrieve
routing information that is used to compute an inter-domain path
satisfying the expressed constraints. An interface MUST be made
available to the PCE so that it can access routing information. Note
that both intra and inter-domain routes MUST be made available to the
PCE.
Boucadair (Ed.) Informational - Expires November 2005 [Page 9]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
In addition, for access control and authorization purposes, the PCE
MUST be provided with access to the list of other PCEs from which it
will accept requests. This list is updated each time new pSLSs are
negotiated by the INP.
9. PCE discovery
Within this document, we assume that during the service negotiation
phase the peers exchange the IP addresses of their respective PCE(s).
This information is stored in the SLS Management Systems of each INP.
As described in [PCE-DISCOVERY], instead of announcing all potential
tail-end addresses in BGP, only an identifier is announced via BGP.
It is called the Path Computation Service Identifier (PCSID). This
particular BGP announcement is identified by a well-known community
value (to be defined by IANA) and is represented by a routable IP
address, which can be different from the real IP address of the PCE.
As a consequence, this particular route SHOULD NOT be installed in
the Forwarding Information Base (FIB) since this PCSID is not
necessarily the IP address of the PCE.
BGP announcements of PCSID will ease to discover the set of remote
ASs supporting the inter-AS MPLS-based QoS tunnels service and
associated end-to-end QoS-related information for reaching them. In
order to compute a path towards a specific domain supporting this
inter-AS MPLS-based QoS tunnels service, the local PCE chooses a
route that serves the PCSID of that domain and extracts from the
AS_PATH attribute the AS number of the next hop ASBR. Then, the local
PCE queries its SLS Management system and gets back the PCE's IP
address of the next neighboring PCE to contact. Finally, the local
PCE forms and forwards a path computation request to the next PCE.
The process is iteratively repeated until the request reaches the PCE
of the target AS identified by its PCSID.
10. PCE to PCE Communication
A PCE can act as a client (Path Computation Client, PCC) or a server
(Path Computation Server, PCS). The PCC is responsible for issuing
Path Computation requests. The PCS is responsible for handling
requests received from PCCs.
The PCP (Path Computation Protocol) is a simple query and response
protocol that is used for communication between PCE entities, i.e.,
PCC and PCS.
+------------+ +------------+
| PCE | | PCE |
Boucadair (Ed.) Informational - Expires November 2005 [Page 10]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
| | | |
| +------+ | | +------+ |
| | PCC | | | | PCC | |
| | |<-|-------\ | | | |
| +--/\--+ | | | +--/\--+ |
| || | |PCP | || |
| || | | | || |
| +--\/--+ | | | +--\/--+ |
| | PCS | | \---------------|->| PCS | |
| | | | | | | |
| +------+ | | +------+ |
+------------+ +------------+
Figure 4: PCC to PCS communication
The main characteristics of the PCP protocol are:
o The protocol employs a client/server model in which a PCE can
both act as a client and/or a server at the same time. A PCE
Client (PCC) sends requests, cancellation and receives
responses.
o The protocol uses TCP as its transport protocol, providing the
reliable exchange of messages between PCEs.
o In its first version, PCP does not provide any message level
security for authentication, message replay protection, and
integrity. However, PCP can reuse existing protocols for
security such as IPSEC [RFC2401] or TLS [RFC2246] to
authenticate and secure the channel between two PCE.
o The current PCP protocol provides the service for supporting
only a basic path computation function. In particular it does
not support the service for additional path computation
constraints, or provide enhanced reporting features in the case
of path computation failure.
11. Routing considerations
11.1. Assumptions
We assume in this document that PCE addresses are only announced in a
few QoS-Class planes. Addresses of LSR/LER interfaces could be
announced in the best effort plane. This reduces the number of BGP
announcements to one announcement per PCE per AS. By setting a well-
known community value, we specify announcements that serve PCEs.
These are not regarded as routes and are not stored in the FIBs.
11.2. Finding inter-domain LSP paths
Boucadair (Ed.) Informational - Expires November 2005 [Page 11]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
In order to find an inter-domain path, the PCE MUST be provided with
a set of attributes including the information describing head-end and
tail-end of the LSP and the performance requirements for the LSP. The
aforementioned information MUST include the loopback IP address of
its LSR, and the IP Address of the PCE of its domain (notation is
IPADDRESS@PCSID). This information MUST also include the performance
guarantees required for the inter-domain constraint-based LSP. This
information MAY encompasses the requested QoS-class(es) so that the
set of collaborating PCE can compute a path that will cross a set of
domain satisfying the expressed constraints.
It can also contain, per QoS-class, additional QoS performance
guarantees that the PCE must take into account. These performance
guarantees include guaranteed end-to-end delay, jitter, loss rate
and/or bandwidth. Note that these parameters can differ depending on
the type of requested QoS-class, and they MAY not all be present in
the LSP set-up request. If included in the path computation request
they MUST be taken into account by the PCE. If the PCE doesn't
recognize a given QoS parameter, the PCE MUST stop its computation
and MUST return an error (PCP Error Message).
When computing a path, a PCE interacts with other blocks of the
management plane. In particular, it checks the availability of the
resources within the boundaries of its domain. If the resources are
available, and the sub-path (path between the ingress point of its
domain and a potential ingress point of a given domain) conforms to
the path constraints requested, it MUST inform the management plane
of a pre-reservation concerning this path. This information can then
be taken into account when processing other path computation
requests. Once this operation succeeds, the request is propagated to
the next domain PCE, which has been selected by the PCE of this
domain.
Note that the performance guarantees requested MUST be updated before
forwarding it to the next domain by taking into account the
performance figures already observed along the computed sub-path plus
the performance figures within its own domain. Therefore, PCE MUST be
aware of the above performance figures of the QoS-classes.
The requesting PCE MUST use the QoS-class identifier they agreed
during the pSLS negotiation phase in order to signal a given QoS-
class.
If an end-to-end LSP has to be re-engineered because the associated
constraints have changed in terms of QoS-class requested, bandwidth,
delay, etc., a new end-to-end path needs to be computed. In order to
improve its chances of finding a valid path, the requestor can
specify that the path for which the request is issued will replace a
previously established LSP. For doing so, the requestor can indicate
the reference of the path corresponding to this LSP. A PCE can
release, during the path computation process, the resources
Boucadair (Ed.) Informational - Expires November 2005 [Page 12]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
corresponding to the former LSP, if the new path follows part of the
former path. This reference is stored in the management plane of each
domain and is generated by the initial requestor. This reference is
globally unique.
The ability to address such additional constraints can be interesting
in the case of backup LSPs, so that the PCE can compute a path along
a different route. These considerations are out of scope of this
document.
12. Communication between PCE and LSR/LER for initiating LSP set-up
Communication between PCE and an LER/LSR could be achieved thanks to
the use of Common Open Policy Service protocol (COPS, [RFC2748]). An
RSVP client-type could be used in order to convey configuration data
resulting from the computation operation executed by a PCE.
Specification of RSVP configuration data is out of scope of this
document.
13. Advanced features
13.1. Exclusion of specific ASs from the path
If a PCE in the chain wants to exclude particular AS(s) from the
path, additional constraints (that can be expressed using the AS
number of the excluded domain/s) MUST be added to the request message
body and MUST be propagated downstream.
13.2. Feedback
When computing a path, the PCEs can fail to find a path for a number
of reasons. These failures, in normal operations, will be mainly due
to the lack of resources, or not meeting the requested QoS
requirements. In such a situation, a path, which would have been the
optimal path, would not be established. Identifying the domain/s
where the path computation failed, together with the reasons, would
be of a real added value for providers in order to improve their
efficiency.
A proposal for achieving this is to rely on the Path Computation
Protocol, which could be improved to return all the path alternatives
which were tried but have failed. In doing so, the requesting
provider would be aware of the reasons of the failure and possibly
interact with that AS where the path computation failed and aborted.
The AS (where the path computation failed), faces with multiple
requests, from external domains, could consider a possible
Boucadair (Ed.) Informational - Expires November 2005 [Page 13]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
modification of some of its peering agreements based on business
objectives.
14. Security Considerations
This document does not change the underlying security issues in the
PCP and BGP protocols specifications. It is recommended that a
security protocol like IPSec or TLS to be activated in order to
protect PCP sessions.
15. References
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
February 2004
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", RFC 3668, February 2004
[RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[INTERAS-PCP] Boucadair M., Morand P., "Inter PCE Communication
Protocol", draft-boucadair-pcp-interas-01.txt, May 2005
[PCE-DISCOVERY] Boucadair M., Morand P., "PCE discovery via Border
Gateway Protocol", draft-boucadair-pce-discovery-01.txt, Work in
progress, May 2005
[RFC2401] Atkinson R., "Security Architecture for the Internet
Protocol", RFC 2401, August 1998
[RFC2246] Dierks T., Allen C., "The TLS Protocol", RFC 2246, January
1999
[RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
16. Acknowledgments
The authors would also like to thank all the partners of the MESCAL
(Management of End-to-End Quality of Service Across the Internet At
Large, http://www.mescal.org) project for the fruitful discussions.
Boucadair (Ed.) Informational - Expires November 2005 [Page 14]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
17. Author's Addresses
Mohamed Boucadair
France Telecom R & D
42, rue des Coutures
BP 6243
14066 Caen Cedex 4
France
Phone: +33 2 31 75 92 31
Email: mohamed.boucadair@francetelecom.com
Pierrick Morand
France Telecom R & D
42, rue des Coutures
BP 6243
14066 Caen Cedex 4
France
Email: pierick.morand@francetelecom.com
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,
Boucadair (Ed.) Informational - Expires November 2005 [Page 15]
Internet Draft A Solution for May 2005
providing inter-AS MPLS-based QoS tunnels
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.
Boucadair (Ed.) Informational - Expires November 2005 [Page 16]
