1 / 8

PCECP Inter-Area Path Computation Requirements

This draft outlines the specific requirements for inter-area path computation using the PCE Communication Protocol (PCECP). It covers topics such as area crossing control, areas recording, inclusion of source/destination area IDs, strict explicit path and loose path, PCE-list enforcement and recording in multiple PCE computation, inter-area diverse path computation, and inter-area policies.

andreahickman
Download Presentation

PCECP Inter-Area Path Computation Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PCECP Specific Requirements for Inter-Area Path Computation draft-ietf-pce-pcecp-interarea-reqs-01.txtJerry Ash (AT&T) Nabil Bitar (Verizon) Dean Cheng (Cisco) Kenji Kumaki (KDDI) J.L. Le Roux (France Telecom) Eiji Oki (NTT) Raymond Zhang (BT Infonet) Renhai Zhang (Huawei) IETF 65, PCE WG, Dallas, 03/20/2006

  2. Changes since last version (1) • The draft has been adopted as WG document after Vancouver meeting • A new co-author joined the draft • Section related to the various PCE-based inter-area path computation approaches (mono-area PCE, multi-area PCE, all-area PCE) has been removed • To be added in a future PCE-based inter-domain applicability statement • As agreed in Vancouver, generic requirements have been moved to the generic ID: • Objective functions • Path reoptimization • Path rerouting • Load balancing path group • Metric selection in a request message • Metric recording in a response message

  3. Changes since last version (2) • Added a requirement on area crossing indication • The response message MUST allow indicating whether the returned path crosses area boundaries. This may be a useful indication when the source and destinations are located within the same area • Added a requirement on Area Recording • A response message MUST support the inclusion of the identifiers of the crossed areas and MUST allow identifying the corresponding path segments • Clarified requirements for inter-area diverse path computation • Some rewordings for the sake of clarity • We now have a 10-page draft, as requested by the chairs 

  4. Next Steps • Sounds quite stable • WG feedback required • A new revision incorporating WG feedback to be posted by the end of April • Then the draft should be ready for WG last call • Time to start working on protocol solutions

  5. ThanksQuestions?

  6. Background and objectives (Reminder) • RFC4105 defines requirements for inter-area MPLS-TE • This includes the computation of end-to-end inter-area constrained shortest path • With as key guideline to respect the IGP hierarchy properties and particularly the containment of routing information • Inter-Area optimal path computation may be achieved using the services of one or more PCEs • This could rely on a single multi-area PCE • This could rely on a cooperation between PCEs in each area • This implies specific requirements on the PCE Communication Protocol (PCECP) • This ID complements generic PCECP requirements by listing a detailed set of requirements specific to inter-area path computation

  7. Requirements summary (1) • Control of area crossing: • The request message MUST allow indicating whether area crossing is allowed or not • The response message MUST allow indicating whether the path crosses area boundaries • Areas recording • A response message MUST support the inclusion of the identifiers of the crossed areas and MUST allow identifying the corresponding path segments • Inclusion of source/destination area IDs in the request • The request message MUST support the inclusion of the source and destination area IDs • Strict explicit path and Loose path • The request message MUST allow indicating whether a Strict Explicit Path is required/desired

  8. Requirements summary (2) • PCE-list Enforcement and Recording in Multiple PCE Computation • The PCECP request message MUST support the inclusion of a list of preferred PCEs • The response message MUST support the recording of the set of one or more PCEs that took part in the computation • Inter-Area Diverse Path computation • The request message MUST allow requesting the computation of a set of inter-area diverse paths between the same node pair or between distinct node pairs • It MUST allow indicating the required level of intra-area diversity (link, node, SRLG) on a per area basis, as well as the level of inter-area diversity (shared ABRs or ABR disjointness) • Inter-Area Policies • The request message MUST allow indicating the orignating PCC • The request message MUST allow indicating that AS crossing is not authorized

More Related