50 likes | 57 Views
This draft proposes extensions to the IGP protocol to enable the discovery of Path Computation Elements (PCEs) and the advertisement of PCE congestion status.
E N D
IGP extensions for PCE Discoverydraft-ietf-pce-disco-proto-igp-01.txtJ.L. Le Roux (France Telecom) J.P. Vasseur (Cisco System Inc.) Yuichi Ikejiri (NTT Communications) Raymond Zhang (BT Infonet) IETF 65, PCE WG, Dallas 03/20/2006
Changes since last version • Draft adopted as WG document after Vancouver meeting • A new co-author joined the draft • The definition and applicability of PCE preferences (in the PATH-SCOPE TLV) has been clarified and illustrated • Added protocol elements and procedures for the advertisement of PCE Congestion Status • Some rewordings for the sake of clarity
The PCES TLV • A new TLV is defined, the PCE Status TLV, to be carried within the ISIS Capability TLV and OSPF Router Information LSA • It carries information related to PCE processing congestion state • Allows advertising when a PCE enters or leaves a processing congestion state • The PCES TLV allows PCCs to take some appropriate actions (e.g. redirect to another PCE) • This includes both the PCC having a PCEP session established with the PCE AND the potential new PCEP peers • TLV content: • A flag indicating whether the PCE is congested or not • An optional field indicating the PCE congestion duration => this allows avoiding the advertisement of congested -> uncongested state transition
Next steps • Advertisement of supported link/path constraints • Need to discuss how to encode the list of supported constraints: • GMPLS link constraints (switching type, encoding type, protection…), • Path constraints (bounded metric, etc.) • Advertisement of supported objective functions • Need to discuss how to encode the list of supported objective functions: e.g. (minimum cost path, widest path, etc.) • WG feedback is required