Comprehensive Requirements for PCE Communication Protocol

1. PCE Communication ProtocolGeneric Requirements(draft-ietf-pce-comm-protocol-gen-reqs-01.txt) Design Team Jerry Ash (AT&T) Alia Atlas (Avici) Arthi Ayyangar (Juniper) Nabil Bitar (Verizon) Igor Bryskin (Independent Consultant) Dean Cheng (Cisco) Durga Gangisetti (MCI) Kenji Kumaki (KDDI) Jean-Louis Le Roux (France Telecom) Eiji Oki (NTT) Raymond Zhang (BT Infonet)

2. PCE Communication ProtocolGeneric Requirements(draft-ietf-pce-comm-protocol-gen-reqs-01.txt) • lists generic requirements for PCE communication protocol • application-specific requirements to be addressed in separate requirements documents • possible PCE-based applications include • intra-area path computation • inter-area path computation • inter-AS intra provider & inter-AS inter-provider path computation • multi-layer path computation & virtual network topology computation/reconfiguration

3. Open Issues • requirements for less constrained path requests/response • currently no consensus for less-constrained path • concerns expressed over complexity • need more WG feedback • requirements for responsiveness & session maintenance • more detailed requirements on throttling messages under overload • specify ‘boundary’ numbers on scalability (# of PCCs, PCEs, domains, path requests, etc.) • need to clearly state supported policy models & corresponding requirements/implications • avoid feature creep • suggest less featured PCE & more robust protocol construction • need to progress application-specific requirements • Inter-area • Inter-AS & Inter-SP • MRN & VNT • PCE protocol proposal needs to identify how generic & application-specific requirements are met • once consensus reached on major issues, propose moving I-D to WG last call

4. Backup Slides

5. PCE Communication Protocol ApplicationExternal PCE Node

6. PCE Communication Protocol ApplicationMultiple PCE Path Computation

7. PCE Communication Protocol ApplicationMultiple PCE Path Computationwith Inter-PCE Communication

8. PCE Communication Protocol (PCECP)Generic Requirements • commonality of PCC-PCE & PCE-PCE communication • MUST use one protocol for both cases • client-server communication • MUST support PCC/PCE request message to request path computation • MUST support PCE response message with computed path • SHOULD support unsolicited communication PCE-PCC • NON-REQUIREMENT to maintain PCC-PCE session • request/response exchange defines limited association between requester & responder • transport • MAY use existing transport protocol or operate directly over IP • transport protocol MAY satisfy reliability & security requirements • transport protocol MUST NOT limit size of messages

9. PCE Communication Protocol (PCECP)Generic Requirements • Path Computation Requests: PCECP MUST • include source & destination • support path constraints (e.g., bandwidth, hops, & affinities to include/exclude) • e.g., exclude points of failure in new path if LSP setup fails • support path reoptimization & inclusion of a previously computed path • allow to select/prefer from advertised list of standard objective functions/options • SHOULD be able to select vendor-specific/experimental objective function/option • allow to customize objective function/options • i.e., set parameters for individual objective functions • specification of objective functions & parameters required in protocol extensibility • PCE response negative if objective function not supported • PCE MAY execute objective functions not advertised to PCC • e.g. policy based path computation for load balancing instructed by management plane

10. PCE Communication Protocol (PCECP)Generic Requirements • Path Computation Requests: PCECP • MAY request a less-constrained path • SHOULD support inclusion of request for less-constrained path, including one or more constraint-relaxation policy’s • Path Computation Responses: PCECP MUST • return computed path(s) & other elements • return any explicit path acceptable for MPLS/GMPLS LSP specified as RSVP-TE ERO • path(s) may be consist of strict or loose hops • hop may be non-simple abstract node • PCE response negative if constraints cannot be satisfied • MAY include reasons for failure & constraints to relax to achieve positive result • MAY provide less-constrained path • SHOULD support inclusion of reasons for failure & less-constrained path reflecting constraint-relaxation policy’s

11. PCE Communication Protocol (PCECP)Generic Requirements • Cancellation of Pending Requests • PCC/PCE MUST be able to cancel pending request • Multiple Requests & Responses: PCECP MUST • support multiple path computation requests in request message • limit by configuration number of requests within a message • support multiple computed paths in response message • corresponding to same request (e.g. load balancing) or distinct requests • support “continuation correlation” where related requests or computed paths cannot fit within one message • maximum message size & maximum number of requests per message • MAY be exchanged through PCE messages to PCC • MAY be indicated in the request message • MAY form part of PCE capabilities advertisement [PCE-DISC-REQ] • implementation MAY limit message size to avoid big message from delaying small message

12. PCE Communication Protocol (PCECP)Generic Requirements • Reliable Message Exchange: PCECP MUST • include reliability • achieved by PCECP itself or transport protocol • allow detection & recovery of lost messages to occur quickly & not impede operation of communication protocol • handle overload situations without significant decrease in performance • e.g., through throttling of requests • provide: • acknowledged message delivery with retransmission • in order message delivery or facility (e.g., message numbering) 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 • functionality SHOULD NOT be added to PCECP if transport protocol provides it

13. PCE Communication Protocol (PCECP)Generic Requirements • Secure Message Exchange: PCECP MUST • be secure • provided by PCECP or transport protocol • support mechanisms to prevent • spoofing (e.g., authentication) • snooping (e.g., encryption) • DOS attacks • Request Prioritization: PCECP MUST • allow PCC to specify priority of a request • priority used by PCE to service high priority requests before lower priority requests • Unsolicited Notifications: PCECP SHOULD • support unsolicited notifications PCE-PCC, PCE-PCE, or PCC-PCE • facilitates communication of updated paths, alerts, etc.

14. PCE Communication Protocol (PCECP)Generic Requirements • Asynchronous Communication: PCECP MUST • allow asynchronous communication • PCC MUST NOT have to wait for response before making another request • allow order of responses differ from order of requests • e.g., when path request messages have different priorities • Communication Overhead Minimization: PCECP SHOULD • minimize communication overhead • give particular attention to message size • other considerations include • number of messages exchanged to arrive at answer • amount of background messages used by PCECP or transport protocol to keep alive any session or PCE-PCC association • processing cost associated with PCECP messages (as distinct from path computation)

15. PCE Communication Protocol (PCECP)Generic Requirements • Extensibility: PCECP MUST • allow introduction of new path computation constraints, diversity types, objective functions, optimization methods, parameters, etc. • without requiring modifications to the protocol • be easily extensible to support applications including: • intra-area path computation • inter-area path computation • inter-AS intra provider & inter-AS inter-provider path computation • multi-layer path & virtual network topology computation/reconfiguration • SHOULD be easily extensible to support future applications not currently in scope of PCE working group • e.g., P2MP path computations, etc. • application specific requirements will be addressed in separate requirements documents

16. PCE Communication Protocol (PCECP)Generic Requirements • Scalability: PCECP MUST • scale 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

17. PCE Communication Protocol (PCECP)Generic Requirements • Constraints: PCECP MUST support • MPLS-TE and GMPLS generic constraints • Bandwidth • Affinities inclusion/exclusion • Link, Node, SRLG inclusion/exclusion • Maximum end-to-end Delay metrics • Hop Count • MPLS-TE specific constraints • Class-Type • GMPLS specific constraints • Switching Type, Encoding Type • Protection type • TBD constraints

18. PCE Communication Protocol (PCECP)Generic Requirements • Support for Different Service Provider Environments: PCECP MUST • operate in various SP environments, such as • MPLS-TE and GMPLS networks • centralized & distributed PCE path computation • single & multiple PCE path computation • Policy Support: PCECP MUST • allow for policies to accept/reject requests • allow PCC to determine reason for rejection • e.g. filtering intra-AS requests: reject requests from another AS • allow for notification of policy violation • policy details left to application-specific PCECP requirements • policies, configuration, & applicability out of scope

19. PCE Communication Protocol (PCECP)Generic Requirements • Aliveness Detection: PCECP MUST • allow PCC to check liveliness of PCEs & PCE to check liveliness of PCCs • provide partner failure detection • MAY be met by PCECP or transport protocol design • PCC/PCE Failure Response: • procedures MUST be defined for PCE/PCC failures • PCC MUST be able to clear any pending request to a PCE • RECOMMENDED that PCC select another PCE upon detection of PCE failure • PCE MUST be able to clear pending requests from a PCC • e.g. when it detects PCC failure or request buffer is full

20. PCE Communication Protocol (PCECP)Generic Requirements • Protocol Recovery: PCECP • MUST support resynchronization of information & requests between sender & receiver • SHOULD minimize repeat data transfer • SHOULD allow PCE to respond to computation requests issued before failure without requests being re-issued • stateful PCE SHOULD be able to resynchronize/recover states (e.g., LSP status, paths) after restart