PCE Working Group Meeting IETF-67, November 2006, San Diego

6
67th IETF, San Diego, November 2006 PCE Working Group Meeting IETF-67, November 2006, San Diego A set of monitoring tools for Path Computation Element based Architecture draft-vasseur-pce- monitoring-01.txt JP Vasseur (jpv@cisco .com )

description

PCE Working Group Meeting IETF-67, November 2006, San Diego. A set of monitoring tools for Path Computation Element based Architecture draft-vasseur-pce-monitoring-01.txt JP Vasseur ( [email protected] ). Quick overview. - PowerPoint PPT Presentation

Transcript of PCE Working Group Meeting IETF-67, November 2006, San Diego

Page 1: PCE Working Group Meeting IETF-67, November 2006, San Diego

67th IETF, San Diego, November 2006

PCE Working Group MeetingIETF-67, November 2006, San Diego

A set of monitoring tools for Path Computation Element based Architecture draft-vasseur-pce-monitoring-01.txt JP Vasseur ([email protected])

Page 2: PCE Working Group Meeting IETF-67, November 2006, San Diego

67th IETF, San Diego, November 2006

Quick overview

• PCE Monitoring: WG item,• The need for OAM functions has been expressed

at several occasions,• Main OAM features specified by this document:

• Check of PCE’s liveness along a path computation chain (may be reduced to a single element) where the set of PCEs may or may not be specified by the PCC,

• Performance metric collection (e.g. processing times, …) related to the PCE(s) involved in the path computation chain for a specific or a general request,

• Standalone functionality or part of a path computation process.

Page 3: PCE Working Group Meeting IETF-67, November 2006, San Diego

67th IETF, San Diego, November 2006

Quick overview

• Monitoring functions can be activated *during* path computation request (PCReq/PCRep messages) or as part of a standalone request (newly defined PCEP messages)

• New PCEP messages: PCMonReq and PCMonRep• New PCEP objects defined:

• MONITORING (carried within PCMonReq/PCMonRep or PCReq/PCRep messages): Check, Record, General, Processing time, Incomplete, Monitoring-id-number,

• PCE-ID (carried within PCMonReq/PCMonRep or PCReq/PCRep messages) : used to record the PCE IP address

• PROC-TIME (carried within PCMonRep/PCRep messages): (Estimated) Current/Min/Max/Average/Variance processing times

Page 4: PCE Working Group Meeting IETF-67, November 2006, San Diego

67th IETF, San Diego, November 2006

Example 1: check of the path computation chain liveness for TE LSP T1 (no path computation), path computation chain unknown

PCE-ID optionally recorded

Three use cases (example shown when the BRPC procedure is in use)

*PCE

ABR1

ABR3 BAArea 0

ABR3

ABR4

*

**

*

B

Area 2Area 1

ABR1

ABR3 BA

ABR3

ABR4

*

**

*

B

Area 2Area 1PCReq message with MONITORING (C=1, P=1), TE LSP attributes.

PCRep message with (optionally) PCE-ID objects + PROC-TIME object

Example 2: Path computation request + performance metric along the path computation chain.

PCE-ID optionally recorded

PCMonReq message with MONITORING (C=1), TE LSP attributes.

PCMonRep message with (optionally) PCE-ID objects

Area 0

Page 5: PCE Working Group Meeting IETF-67, November 2006, San Diego

67th IETF, San Diego, November 2006

Example 3: performance metric gathering for a general request along a specific path computation chain (ABR1-ABR4)

Three use case (example shown when the BRPC procedure is in use)

ABR1

ABR3 BAArea 0

ABR3

ABR4

*

**

*

B

Area 2Area 1

PCMonReq message with MONITORING (C=1), set of PCE-IDs specified

PCMonRep message with (optionally) PCE-ID objects + PROC-TIME

Page 6: PCE Working Group Meeting IETF-67, November 2006, San Diego

67th IETF, San Diego, November 2006

Conclusion

• Comments have been received on the list, new items to be covered in the next revision, details on procedures,

• New metrics can easily be added in future revisions (e.g. Timestamping, queues states, …) without any change to the architecture

• Is there a WG support for such functionality ?• WG ID ?