1 / 9

H. Pouyllau R. Theillaud J. Meuric

Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications draft-pouyllau-pce-enhanced-errors-03. H. Pouyllau R. Theillaud J. Meuric. Outline. Motivation and proposal Changes in -03 Conclusion. Motivation. PCErr and PCNtf

faulkm
Télécharger la présentation

H. Pouyllau R. Theillaud J. Meuric

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. Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notificationsdraft-pouyllau-pce-enhanced-errors-03 H. Pouyllau R. Theillaud J. Meuric

  2. Outline • Motivation and proposal • Changes in -03 • Conclusion

  3. Motivation PCErr and PCNtf • Some error and notification types/values are standardized • No common rules Extending error and notification codes and specify associated behaviors is a need for: • Enhancing PCE functionalities • Notifications can be used for particular functions (PCE policing, discovery, etc.) • Improving the coordination among PCE systems • Anticipating future evolutions of the standard Examples • Path computation methods (e.g. Hierarchical PCE End-to-End) might require the propagation of errors or notifications to PCEs involved in a path computation

  4. Proposal Standardize error and notification attributes • Allows specifying the criticality of errors and the type of notifications (request-specific or not) • Allow specifying the propagation behavior Restriction mechanisms • A Time-To-Live object: to limit the number of PCEP peers that will recursively receive the message • A Diffusion List Object (DLO): to indicate the PCEP peer addresses or domains of PCEP peers the message must be propagate to and to exclude some domains or PCEs; • History mechanisms: if a PCEP peer keeps track of the messages it has relayed, it could avoid propagating several times the same error/notification to the same peers.

  5. Outline • Motivation and proposal • Changes in -03 • Conclusion

  6. Points raised on the mailing-list • 1) Error type is more related to a family of errors, in the draft it indicates a kind of processing indication. Use means of TLVs rather than types for each possible option (propagation, shutdown, etc.) • 3 new TLVs defined • 2) A warning can be raised either as an error or as a notification • Allows all possible combinations with restrictions • 3)DLO • Example: a PCE wants to advertize to all the PCEs of the AS it belongs to that it is congested. The DLO object (in the manner of the IRO) can be used for that

  7. Changes with -02: from types to TLVs • Propagation TLV: • 0 : the message MUST NOT be propagated • 1: the message MUST be propagated • Error-criticality TLV: • 0: low-level, further messages can be expected for this request • 1: medium-level, identifiers appear MUST be cancelled , no further messages can be expected for these requests • 2: high-level, connection is closed by the sender PCE peer • Notification type TLV: • 0: request-specific • 1: not request-specific

  8. Outline • Motivation and proposal • Changes in -03 • Conclusion

  9. Conclusion • Extending PCEP to generalize error and notification behaviors • Give a common error/notification framework for existing and future path computation methods • Propagation restrictions have been clarified • Impacts on existing RFCs have been listed • WG approval as a WG document

More Related