Path Computation Element (PCE) communication Protocol (PCEP) draft-vasseur-pce-pcep-01.txt

1. Path Computation Element (PCE) communication Protocol (PCEP)draft-vasseur-pce-pcep-01.txt Jean-Philippe Vasseur (jpv@cisco.com) Jean-Louis Le Roux (jeanlouis.leroux@francetelecom.com) Eiji Oki (oki.eiji@lab.ntt.co.jp ) Arthi Ayyangar (arthi@juniper.net) Alia Atlas (akatlas@alum.mit.edu ) 63th IETF, Paris, August 2005

2. Background • PCE Working Group item: “Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs.” • Background: • draft-vasseur-mpls-computation-rsvp-05.txt --> discontinued • draft-oki-ccamp-gtep-01.txt --> discontinued • A completely new protocol has been designed (PCEP) highly driven by the PCE communication protocol requirement produced by the WG: draft-ietf-pce-comm-protocol-gen-reqs-01.txt with the chief objective to be extensible to support extensions addressing further application-specific requirements. 63th IETF, Paris, August 2005

3. Background • First revision of PCEP produced in May 2005. • Second revision posted in July 2005. Incorporates the comments received from Igor Bryskin, Jerry Ash and Adrian Farrel (thanks) • Major changes in rev-01: • Some sections have been rewritten for clarity, • Few sections removed, • New section related to the “Protocol Model” (RFC4101) • New Security consideration section • New Manageability consideration section (to be fleshed out) • Two new objects defined: • NO-PATH (negative reply with (optional) cause) • ENCAP (used to carry other protocol’s object(s)) 63th IETF, Paris, August 2005

4. A quick overview … (no presentation … the goal of this meeting is to discuss the issues) • A unique communication protocol for PCC-PCE and PCE-PCE • PCEP relies on TCP for transport: fulfils the requirements for reliable transport with flow control with no further protocol work • See the discussion on “permanent” versus “per-request” mode • 4 message types: • Path computation request (PCReq) PCC --> PCE • Path computation reply (PCRep) PCC <-- PCE • Notification (PCNtf) PCC <--> PCE • Protocol Error (PCErr) PCC <--> PCE 63th IETF, Paris, August 2005

5. Initiation Phase: TCP session PCC PCE PCC PCE Path Comp requested PCE selection Path comp request X sent Path Comp requested PCE selection Path comp request sent PCReq PCReq 4) Path Comp triggered 4) Path Comp triggered No path found PCNtf PCRep 5) Negative reply sent to PCC (optionally with less-constrained path) 5) Path Computation X cancelled 6) Path computation X cancelled Path computation request and reply PCC PCE PCC PCE Path Comp requested PCE selection Path comp request X sent Path Comp requested PCE selection Path comp request sent PCReq PCReq 4) Path Comp triggered 4) Path Comp triggered Successful computation 5) Computed path(s) sent to the PCC 5) PCE experiencing congestion PCRep PCNtf 6) Path computation X cancelled Notification (example) Path computation request and reply Protocol Model Notification (example) 63th IETF, Paris, August 2005

6. A quick overview … (no presentation … the goal of this meeting is to discuss the issues) • Various Objects (Mandatory/Optional): • REQUEST-ID: ID # + request attributes (Pri, L, R, B, C, E) • NO-PATH: negative reply with optional cause • END-POINTS: source/destination • BANDWIDTH, DELAY • IRO, XRO: inclusion/exclusion of specific network elements • CVEC: correlation of a set of request-ids • NOTIFICATION: Pending requests cancelled, congested state, … • PCEP-ERROR: protocol error condition • ENCAP 63th IETF, Paris, August 2005

7. Compliance with draft-ietf-pce-comm-protocol-gen-reqs-01 Secure Message Exchange (provided by PCEP or transport protocol MUST Support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., encryption), DOS attacks MUST Request Prioritization MUST Allow Asynchronous Communication MUST PCC Has to Wait for Response Before Making Another Request MUST NOT Allow order of responses differ from order of requests MUST Extensibility without requiring modifications to the protocol MUST Easily extensible to support intra-area, inter-area, inter-AS intra provider, inter-AS, inter-provider, multi-layer path & virtual network topology path computation MUST Scalability at least linearly with increase in number of PCCs, PCEs, PCCs communicating with a single PCE, PCEs communicated to by a single PCC, PCEs communicated to by another PCE, domains, path requests, handling bursts of requests MUST Support Path Computation Constraints MUST Support Different Service Provider Environments (e.g., MPLS-TE and GMPLS networks, centralized & distributed PCE path computation, single & multiple PCE path computation) MUST Policy Support for policies to accept/reject requests, PCC to determine reason for rejection, notification of policy violation MUST Aliveness Detection of PCCs/PCEs, partner failure Detection MUST PCC/PCE Failure Response procedures defined for PCE/PCC failures, PCC able to clear pending request MUST PCC select another PCE upon detection of PCE failure MUST PCE able to clear pending requests from a PCC (e.g. when it detects PCC failure or request buffer full) MUST Protocol Recovery support resynchronization of information & requests between sender & receiver MUST • PCEP meets the vast majority of the requirements • Open issues: • Objective functions … to be done in next revision • Protocol recovery … requires more detailed requirements • Policy … requires more discussion Commonality of PCC-PCE and PCE-PCE Communication MUST Client-Server Communication MUST Support PCC/PCE request message to request path computation MUST Support PCE response message with computed path MUST Transport Protocol Limits Size of Message MUST NOT Support Path Computation Requests MUST Include source & destination Support path constraints (e.g., bandwidth, hops, affinities) to include/exclude MUST Support path reoptimization & inclusion of a previously computed path MUST Allow to select/prefer from advertised list of standard objective functions/options MUST Allow to customize objective function/options MUST Support Path Computation Responses MUST Cancellation of Pending Requests MUST Multiple Requests and Responses MUST Limit by configuration number of requests within a message MUST Support multiple computed paths in response MUST Support "continuation correlation" where related requests or computed paths cannot fit within one message MUST Reliable Message Exchange (achieved by PCEP itself or transport protocol MUST Allow detection & recovery of lost messages to occur quickly & not impede operation of PCEP MUST Handle overload situations without significant decrease in performance, e.g., through throttling of requests MUST Provide acknowledged message delivery with retransmission, in order message delivery or facility to restore order, message corruption detection, flow control & back-pressure to throttle requests, rapid partner failure detection, informed rapidly of failure of PCE-PCC connection MUST 63th IETF, Paris, August 2005

8. Discussion on open issues .. 1) Is there a requirement for PCEP hello message that could be used for faster PCC/PCE liveness detection? 2) Initiation phase: currently limited to TCP session establishment. Is there a need for an Initiation phase during which several PCEP session attributes could be negotiated such as: • The session mode. Does the PCC or PCE require to have a permanent PCEP session in which case the TCP session will be maintained regardless of the rate at which PCEP messages are exchanged? Such mode would typically be used to speed-up response times. A lost of TCP session should in this mode be interpreted as a communication failure. Conversely, in the “per-request” mode, a PCEP session would be established on-demand, when one or more path computation requests is required and then closed by the PCC. 63th IETF, Paris, August 2005

9. Discussion on open issues .. • The PCE detailed parameters: as stated in [PCE-DISC], there is a requirement for an automatic discovery of the PCE attributes. If required, detailed PCE attributes could be discovered by means of the PCEP protocol during the PCEP Initiation phase. • If there is a requirement for PCEP hello message, the frequency at which hello messages are exchanged could be negotiated during the Initiation phase? • Specific policies could be exchanged during the Initiation phase. 3) In its current version, PCEP provides the ability for a PCC to notify to the PCE its interest in less-constrained TE LSP and for the PCE to provide less-constrained computed path(s). --> No WG consensus as of now, --> Advanced functionality => Plan to take it out of the main PCEP specification (separate ID to be discussed) 63th IETF, Paris, August 2005