--- 1/draft-ietf-pce-monitoring-05.txt 2009-12-15 21:12:36.000000000 +0100 +++ 2/draft-ietf-pce-monitoring-06.txt 2009-12-15 21:12:36.000000000 +0100 @@ -1,22 +1,44 @@ Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status: Standards Track JL. Le Roux -Expires: December 14, 2009 France Telecom +Expires: June 17, 2010 France Telecom Y. Ikejiri NTT Communications Corporation - June 12, 2009 + December 14, 2009 A set of monitoring tools for Path Computation Element based Architecture - draft-ietf-pce-monitoring-05.txt + draft-ietf-pce-monitoring-06.txt + +Abstract + + A Path Computation Element (PCE) based architecture has been + specified for the computation of Traffic Engineering (TE) Label + Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and + Generalized MPLS (GMPLS) networks in the context of single or + multiple domains (where a domain refers to a collection of network + elements within a common sphere of address management or path + computational responsibility such as IGP areas and Autonomous + Systems). Path Computation Clients (PCCs) send computation requests + to PCEs, and these may forward the requests to and cooperate with + other PCEs forming a "path computation chain". + + In PCE-based environments, it is thus critical to monitor the state + of the path computation chain for troubleshooting and performance + monitoring purposes: liveness of each element (PCE) involved in the + PCE chain, detection of potential resource contention states and + statistics in term of path computation times are examples of such + metrics of interest. This document specifies procedures and + extensions to the Path Computation Element Protocol (PCEP) in order + to gather such information. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -25,54 +47,36 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 14, 2009. + This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - A Path Computation Element (PCE) based architecture has been - specified for the computation of Traffic Engineering (TE) Label - Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and - Generalized MPLS (GMPLS) networks in the context of single or - multiple domains (where a domain refers to a collection of network - elements within a common sphere of address management or path - computational responsibility such as IGP areas and Autonomous - Systems). Path Computation Clients (PCCs) send computation requests - to PCEs, and these may forward the requests to and cooperate with - other PCEs forming a "path computation chain". - - In PCE-based environments, it is thus critical to monitor the state - of the path computation chain for troubleshooting and performance - monitoring purposes: liveness of each element (PCE) involved in the - PCE chain, detection of potential resource contention states and - statistics in term of path computation times are examples of such - metrics of interest. This document specifies procedures and - extensions to the Path Computation Element Protocol (PCEP) in order - to gather such information. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Path Computation Monitoring messages . . . . . . . . . . . . . 6 3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11 @@ -81,34 +85,34 @@ 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 17 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18 7. Manageability Considerations . . . . . . . . . . . . . . . . . 20 7.1. Control of Function and Policy . . . . . . . . . . . . . . 20 7.2. Information and Data Models . . . . . . . . . . . . . . . 20 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 - 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 20 + 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21 8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22 8.6. CONGESTION Object Flag field . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The Path Computation Element (PCE) based architecture has been specified in [RFC4655] for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such Interior Gateway Protocol (IGP) @@ -663,26 +667,34 @@ Average-processing-time: This field indicates in milliseconds the average processing time. Variance-processing-time: This field indicates in milliseconds the variance of the processing times. 4.4. CONGESTION Object The CONGESTION object is used to report a PCE processing congestion - state. The CONGESTION object MUST be present within a PCMonRep or a - PCRep message if the C bit of the MONITORING object carried within - the corresponding PCMonReq or PCReq message is set and the PCE is + state. Note that "congestion" as indicated by this object refers to + the processing state of the PCE and its ability to handle new PCEP + requests. A PCE is congested when it has a backlog of PCEP requests + such that it cannot immediately start to process a new request thus + leading to waiting times. The congestion duration is quantified as + being the (estimated) time until the PCE expects to be able to + immediately process a new PCEP request. + + The CONGESTION object MUST be present within a PCMonRep or a PCRep + message if the C bit of the MONITORING object carried within the + corresponding PCMonReq or PCReq message is set and the PCE is experiencing a congested state. The CONGESTION Object-Class is to be - assigned by IANA (recommended value=22) The CONGESTION Object-Type is - to be assigned by IANA (recommended value=1) + assigned by IANA (recommended value=22). The CONGESTION Object-Type + is to be assigned by IANA (recommended value=1) The format of the CONGESTION object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Congestion Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits - No flag is currently defined. @@ -889,22 +901,22 @@ Error-type Meaning Error-value Reference 6 Mandatory Object missing 4 This document MONITORING Object missing 8.4. MONITORING Object Flag Field IANA is requested to create a registry to manage the Flag field of the MONITORING object. - New bit numbers may be allocated only by an IETF Consensus action. - Each bit should be tracked with the following qualities: + New bit numbers may be allocated only by an IETF review. Each bit + should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability Description o Defining RFC Several bits are defined for the MONITORING Object flag field in this document: @@ -915,53 +927,53 @@ 20 Congestion This document 21 Processing Time This document 22 General This document 23 Liveness This document 8.5. PROC-TIME Object Flag Field IANA is requested to create a registry to manage the Flag field of the PROC-TIME object. - New bit numbers may be allocated only by an IETF Consensus action. - Each bit should be tracked with the following qualities: + New bit numbers may be allocated only by an IETF review. Each bit + should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability Description o Defining RFC One bit is defined for the PROC-TIME Object flag field in this document: Codespace of the Flag field (PROC-TIME Object) Bit Description Reference 0-14 Unassigned 15 Estimated This document 8.6. CONGESTION Object Flag field IANA is requested to create a registry to manage the Flag field of the CONGESTION object. - New bit numbers may be allocated only by an IETF Consensus action. - Each bit should be tracked with the following qualities: + New bit numbers may be allocated only by an IETF review. Each bit + should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability Description o Defining RFC - One bit is defined for the CONGESTION Object flag field in this - document: + No Flag are currently defined for the CONGESTION Object flag field in + this document. Codespace of the Flag field (CONGESTION Object) Bit Description Reference 0-7 Unassigned 9. Security Considerations The use of monitoring data can be used for various attacks such as denial of service attacks (for example by setting the C bit and congestion during field of the CONGESTION object to stop PCCs from