1 pce communication protocol generic requirements (draft-ietf-pce-comm-protocol-gen-reqs-01.txt)...

1

PCE Communication ProtocolGeneric Requirements

(draft-ietf-pce-comm-protocol-gen-reqs-01.txt)

Design TeamJerry 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

---------- | ----- | | | TED |<-+------------> | ----- | TED synchronization | | | mechanism (for example, routing protocol) | | | | v | | ----- | | | PCE | | | ----- | ---------- ^ | Request/ | Response v Service ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | ---->| Node |<---------->| Node | ---------- ----------

6

PCE Communication Protocol ApplicationMultiple PCE Path Computation

---------- ---------- | | | | | PCE | | PCE | | | | | | ----- | | ----- | | | TED | | | | TED | | | ----- | | ----- | ---------- ---------- ^ ^ | Request/ | Request/ | Response | Response v v Service ---------- Signaling ------------- Signaling ------------ Request| Head-End | Protocol |Intermediate | Protocol |Intermediate| ---->| Node |<---------->| Node |<--------->| Node | ---------- ------------- ------------

7

PCE Communication Protocol ApplicationMultiple PCE Path Computationwith Inter-PCE Communication

---------- ---------- | | Inter-PCE Request/Response | | | PCE |<--------------------------------->| PCE | | | | | | ----- | | ----- | | | TED | | | | TED | | | ----- | | ----- | ---------- ---------- ^ | Request/ | Response v Service ---------- Signaling ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | ---->| Node |<---------->| Node |<---------->| Node | ---------- ---------- ----------

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


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


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


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


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


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


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


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


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


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


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


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


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

1 pce communication protocol generic requirements (draft-ietf-pce-comm-protocol-gen-reqs-01.txt)...

Documents