Network Working Group J.L. Le Roux
Internet Draft France Telecom
Category: Standard Track
Expires: September 2007 R. Jacob
Brighthaul
R. Douville
Alcatel-Lucent
March 2007
Carrying a Contract Identifier in the PCE communication Protocol (PCEP)
draft-leroux-pce-contract-id-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Le Roux, Jacob, Douville PCE Contract ID [Page 1]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
Abstract
The Path Computation Element (PCE) based architecture can be used for
computing Traffic Engineered Label Switched Paths (TE LSP) that
traverse multiple Autonomous Systems (AS) in MultiProtocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks. This may
require communication between PCEs in each AS, based upon on the PCE
communication Protocol (PCEP). When ASes belong to distinct service
providers, a per-service negotiation and activation procedure may be
required before starting PCE based path computation. For the sake of
illustration, the IPSphere Forum (IPSF) is currently specifying an
architecture so as to automate the negotiation and activation of such
an inter-provider TE LSP service. The result of such negotiation is a
per-service contract identifier that needs to be carried in PCEP, so
that PCEs can apply inter-provider path computation policies. For
that purpose, this draft defines an extension to the PCEP protocol so
as to carry a contract ID in request messages.
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.
Table of Contents
1. Terminology.................................................3
2. Introduction................................................3
3. PCEP CONTRACT-ID Object definition..........................4
3.1. Carrying the CONTRACT-ID object in PCReq messages...........5
4. Elements of procedure.......................................6
5. IANA Considerations.........................................7
5.1. CONTRACT-ID Object..........................................7
5.2. PCEP Error values...........................................7
6. Backward Compatibility......................................7
7. Security Considerations.....................................7
8. Manageability Considerations................................7
9. Acknowledgments.............................................7
10. References..................................................8
10.1. Normative references........................................8
10.2. Informative references......................................8
11. Author's Addresses:.........................................8
12. Intellectual Property Statement.............................9
Le Roux, Jacob, Douville PCE Contract ID [Page 2]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
1. Terminology
Terminology used in this document
PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph, and applying computational
constraints.
BRPC: Backward Recursive PCE based path Computation. Procedure
relying on inter-PCE communication to compute shortest inter-
domain Traffic Engineering Label Switched Paths.
Inter-AS TE LSP: A TE LSP whose path transits two or more
ASes or sub-ASes (BGP confederations). That is a TE LSP that
crosses at least one AS boundary.
Inter-Provider TE LSP: A TE LSP whose path transits two or more
providers. That is a TE LSP that crosses at least one provider
boundary.
PCEP: Path Computation Element communication Protocol.
TE LSP: Traffic Engineered Label Switched Path.
AS: Autonomous System.
UUID: Universally Unique IDentifier.
IPSF: IPSphere Forum.
2. Introduction
The PCE-based network architecture [RFC4655] defines a Path
Computation Element (PCE) as an entity capable of computing TE LSP
paths based on a network graph, and applying computational
constraints. A PCE serves path computation requests sent by Path
Computation Clients (PCC). The PCE communication Protocol (PCEP)
[PCEP], allows for communication between a PCC and a PCE or between
two PCEs, in compliance with requirements and guidelines set forth in
[RFC4657]. Such interactions include path computation requests and
path computation replies.
The computation of inter-AS TE LSPs may rely on the Backward
Recursive PCE based path Computation (BRPC) procedure that allows
Le Roux, Jacob, Douville PCE Contract ID [Page 3]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
computing shortest inter-domain paths ([BRPC]). This relies upon one
PCE per AS, with PCEP based inter-PCE communication.
The computation of inter-provider TE LSPs may require, at the service
and management plane levels, a preliminary service negotiation and
activation procedure, between the set of providers the LSP will
traverse. For the sake of illustration, the IPSphere Forum (IPSF) is
currently working on a framework for the automatic negotiation and
activation of an inter-provider TE LSP service [IPSF-IC-MPLS]. The
result of such a negotiation is a contract identifier in the form of
a Universally Unique IDentifier (UUID) (as per defined in [RFC4122]),
which is then used to identify the agreed service and apply policies
to control plane messages, including request acceptance/rejection as
well as Traffic Engineering parameters filtering and translation.
This contract identifier has to be carried in the PCEP protocol so
that path computation requests can be policed according to the
beforehand agreed service.
For that purpose, this draft defines extensions to the PCE
communication Protocol (PCEP) so as to transparently transport a
service contract identifier in request messages. A new PCEP CONTRACT-
ID object is defined, to be carried in PCReq messages, the content of
which is transparent and not processed at the PCEP level. The
CONTRACT-ID object is communicated to a service Policy Decision Point
(PDP) to apply policies (request acceptance/rejection, TE parameters
filtering/translation, next-AS determination, etc.). There is no
assumption on the way the object is communicated to the PDP, as well
as on the actual location of the PDP; this is beyond the scope of
this document.
Note that the use of policies within the PCE Architecture is
extensively discussed in [PCE-POLICY].
3. PCEP CONTRACT-ID Object definition
The PCEP CONTRACT-ID object defined in this document is compliant
with the PCEP object format defined in [PCEP].
The PCEP CONTRACT-ID object is optional, it MAY be carried within a
PCReq message. It carries the identifier of the TE LSP service
contract that has been negotiated and instantiated at the service
level, between all service providers along the LSP path. It allows
applying policies to the inter-provider path computation requests,
based upon the beforehand agreed service.
When carried in a PCReq message, this object has to be supported by
the PCE, and hence, according to [PCEP], the P flag in the object
header MUST always be set.
Le Roux, Jacob, Douville PCE Contract ID [Page 4]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
The Contract-ID Object-Class is to be assigned by IANA (recommended
value=19).
The Contract-ID Object-Type is to be assigned by IANA (recommended
value=1).
The format of the Contract-ID object body is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| 128 bit Contract-ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Contract-ID (128 bit): Identifier of the inter-provider TE LSP
service, instantiated at the service level. It is encoded as a
Universally Unique IDentifier (UUID) as per defined in [RFC4122].
3.1. Carrying the CONTRACT-ID object in PCReq messages
The CONTRACT-ID object MAY be carried within a PCReq message. It is
carried after the RP object for which it applies.
The format of the PCReq message, defined in [PCEP], is updated as
follows:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
[<CONTRACT-ID>]
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
Le Roux, Jacob, Douville PCE Contract ID [Page 5]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
4. Elements of procedure
The CONTRACT-ID object MAY be used during PCE based inter-provider
path computation with inter-PCE communication.
The P bit in the object header MUST always be set.
On receipt of a PCReq message with a CONTRACT-ID object, a PCE MUST
proceed as follows:
- If the object is unknown or unsupported, the PCE follows
procedures defined in [PCEP], that is, as the P flag is set, it
sends a PCErr message with error type unknown object (type
3), or unsupported object (type 4) respectively.
- If the object is supported, it MUST not be processed at the
PCEP level and MUST be transparently passed to a Policy Decision
Point (PDP) so as to apply service policies based upon the
contract identifier (this may include request acceptance /
rejection, TE parameters filtering / translation, next-AS
determination, etc.):
- If the request is accepted and the PCReq message has
to be propagated to a downstream PCE, the downstream
PCReq message MUST contain a CONTRACT-ID object whose
contract id value is determined by policy decision; this
may be the same or a distinct value (to support cases
where the next provider PCE has a different contract
ID).
- If the request is rejected due to service policies,
the PCReq message MUST not be propagated downstream, and
the PCE MUST send upstream a PCErr message with error-
type policy violation (type 5) and an error value
indicating the reasons for the rejection. Three new
error values are defined in this document for service
policies: "service admission control failure", "service
parameter violation", and "unknown contract ID".
Le Roux, Jacob, Douville PCE Contract ID [Page 6]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
5. IANA Considerations
5.1. CONTRACT-ID Object
The IANA has been requested to manage the PCEP Objects code point
registry (see [PCEP]).
This document defines a new PCEP object, the CONTRACT-ID object to
be carried in PCReq messages. The IANA is requested to make the
following allocation (suggested value):
Object Name Object Name Reference
Class Type
19 CONTRACT-ID 1 Contract (this document)
Identifier
5.2. PCEP Error values
Three new error values are defined for the error type "policy
violation":
Error-type Meaning and error values Reference
5 Policy violation
Error-value=5: service admission control (this doc)
failure (request rejected)
Error-value=6: service parameter violation (this doc)
(request rejected)
Error-value=7: unknown contract-ID (this doc)
(request rejected)
6. Backward Compatibility
TBC
7. Security Considerations
TBC
8. Manageability Considerations
TBC
9. Acknowledgments
We would like to thank Dimitri Papadimitriou for the useful comments.
Le Roux, Jacob, Douville PCE Contract ID [Page 7]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
10. References
10.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE)-based Architecture", RFC4655, august 2006.
[PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE)
communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work
in progress.
[RFC4122] P. Leach, M. Mealling, R. Salz, " A Universally Unique
IDentifier (UUID) URN Namespace", RFC4122, July 2005.
10.2. Informative references
[RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic
Requirements", RFC4657, September 2006.
[BRPC] Vasseur, Zhang, Bitar, Le Roux, " A Backward Recursive PCE-
based Computation (BRPC) procedure to compute shortest inter-domain
Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc, work
in progress.
[IPSF-IC-MPLS] Drai, R., Jacob, Y., Le Roux, J.L., Vasseur, J.P.,
"Inter-Carrier Traffic-Engineering LSP Component use-case
architecture spec", IPSF Reference Architecture WG draft, work in
progress.
[PCE-POLICY] Bryskin, Papadimitriou, Berger, "Policy Enabled Path
Computation Framework", draft-ietf-pce-policy-enabled-path-comp, work
in progress.
11. Author's Addresses:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com
Le Roux, Jacob, Douville PCE Contract ID [Page 8]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
Ron Jacob
Brighthaul
16 Galgalei Haplada, Herzelia
ISRAEL
Email: ron@brighthaul.com
Richard Douville
Alcatel-Lucent
Centre de Villarceaux
91620 Nozay
FRANCE
Email: richard.Douville@alcatel-lucent.fr
12. 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, 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.
Copyright Statement
Le Roux, Jacob, Douville PCE Contract ID [Page 9]
Internet Draft draft-leroux-pce-contract-id-01.txt March 2007
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.
Le Roux, Jacob, Douville PCE Contract ID [Page 10]