One document matched: draft-vasseur-pce-monitoring-00.txt
Networking Working Group JP. Vasseur
Internet-Draft Cisco Systems, Inc
Intended status: Standards Track October 10, 2006
Expires: April 13, 2007
A set of monitoring tools for Path Computation Element based
architecture
draft-vasseur-pce-monitoring-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six months
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 April 13, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A Path Computation Element (PCE) based architecture has been
specified for the computation of constrained shortest Traffic
Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context
of single or multiple across multiple domains (where a domain is
referred to as a collection of network elements within a common
sphere of address management or path computational responsibility
Vasseur Expires April 13, 2007 [Page 1]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
such as IGP areas and Autonomous Systems). In such PCE-based
environment it is thus critical to monitor the state of the path
computation chain and potentially gather various performance metrics
with regards to the set of involved PCE(s) that can used for
performance monitoring and troubleshooting purposes so as to identify
a potential bottleneck in the path computation chain. This document
specifies procedures and extensions to the Path Computation Element
Protocol (PCEP) in order to gather such information.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Path Computation Monitoring messages . . . . . . . . . . . . . 4
3.1. Path Computation Monitoring Request message (PCMonReq) . . 5
3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 6
4. Path Computation Monitoring Objects . . . . . . . . . . . . . 7
4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 7
4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 8
4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 9
4.4. TIMESTAMP Object . . . . . . . . . . . . . . . . . . . . . 11
5. Multi-destination monitoring . . . . . . . . . . . . . . . . . 11
6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Element of procedure . . . . . . . . . . . . . . . . . . . . . 12
8. Manageability Considerations . . . . . . . . . . . . . . . . . 12
9. To be considered in a further revision of this document . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Vasseur Expires April 13, 2007 [Page 2]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
1. Terminology
ABR: routers used to connect two IGP areas (areas in OSPF or levels
in IS-IS).
ASBR: routers used to connect together ASs of a different or the same
Service Provider via one or more Inter-AS links.
Boundary Node (BN): a boundary node is either an ABR in the context
of inter- area TE or an ASBR in the context of inter-AS TE.
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n).
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1).
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
LSR: Label Switching Router.
LSP: Label Switched Path.
PCE (Path Computation Element): an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
PCE(i) is a PCE with the scope of domain(i).
TED: Traffic Engineering Database.
2. Introduction
The Path Computation Element (PCE) based architecture has been
specified in [RFC4655] for the computation of constrained shortest
Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the
context of single or multiple across multiple domains (where a domain
is referred to as a collection of network elements within a common
sphere of address management or path computational responsibility
such as IGP areas and Autonomous Systems).
In such PCE-based environment it is thus critical to monitor the
state of the path computation chain and potentially gather various
performance metrics with regards to the set of involved PCE(s) that
can used for performance monitoring and troubleshooting purposes so
as to identify a potential bottleneck in the path computation chain.
Vasseur Expires April 13, 2007 [Page 3]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
This document specifies procedures and extensions to the Path
Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to
monitor the path computation chain and gather various performance
metrics. As discussed in [RFC4655], a TE LSP may be computed by one
PCE (referred to as ) or several PCE (referred to as Multi-PCE). In
the former case, the PCC may be able to use IGP extensions to check
the availability of the PCE (see [I-D.ietf-pce-disco-proto-ospf] and
[I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages.
In constrast, when multiple PCEs are involved in the path computation
chain an example of which being the use of the BRPC procedure defined
in [I-D.ietf-pce-brpc], the PCC's visibility is limited to the first
involved PCE. Thus, it is critical to define mechanisms in order to
gether performance metrics along the path computation chain (e.g.
liveness, path computation time at each PCE, propagation delays
experienced by the path computation request betwen each PCE involved
in the path computation chain and so on).
3. Path Computation Monitoring messages
As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a
common header followed by a variable length body made of a set of
objects that can either be mandatory or optional. Furthermore, an
object is said to be mandatory in a PCEP message when the object MUST
be included for the message to be considered as valid. Thus a PCEP
message with a missing mandatory object MUST be considered as a
malformed message and such condition MUST trigger an Error message.
Conversely, if an object is optional, the object may or may not be
present. The use of the P flag is defined in [I-D.ietf-pce-pcep].
As a reminder, the P flag is located in the common header of each
PCEP object that can be set by a PCEP peer to enforce a PCE to take
into account the related information during the path computation.
Because the P flag exclusively relates to a path computation request,
it MUST be cleared in the two PCEP messages (PCEMonReq and PCMonRep
message) defined in this document.
For each PCEP message type a set of rules is defined that specify the
set of objects that the message can carry. We use the Backus-Naur
Form (BNF) to specify such rules. Square brackets refer to optional
sub-sequences. An implementation MUST form the PCEP messages using
the object ordering specified in this document.
In this document we define two new PCEP messages referred to as the
Path Computation Monitoring request (PCMonReq) and Path Computation
Monitoring Reply (PCMonRep) message. The aim of the PCMonReq message
sent by a PCC to a PCE is to gather performance metrics on a set of
PCEs involved in a path computation chain. The PCMonRep message sent
by a PCE to a PCC is used to provide such data.
Vasseur Expires April 13, 2007 [Page 4]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
3.1. Path Computation Monitoring Request message (PCMonReq)
The Message-Type field of the PCEP common header for the PCMonReq
message is set to 8 (To be confirmed by IANA).
There is one mandatory object that MUST be included within a PCMonReq
message: the Monitoring object (see section Section 4.1). If the
Monitoring object is missing, the receiving PCE MUST send an error
message to the sender. Other objects are optional.
The format of a PCReq message is as follows:
<PCMonReq Message>::= <Common Header>
<MONITORING>
[<lsp-request>]
[<pce-list>]
where:
<lsp-request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<METRIC>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
<pce-list>::=<pce>[<pce-list>]
<pce>::= [<PCE-ID>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD-
BALANCING objects are defined in [I-D.ietf-pce-pcep].
A PCMonReq message is sent to gather various performance metrics
along a path computation chain. Such metrics may relate to a
specific path computation chain encoded in the form of a series of
PCE-ID objects defined in Section 4.2. Alternatively, it may be
desired to collect such performance metrics along the path
computation chain involved to compute a TE LSP. In that case, the TE
LSP attributes are characterized by the set of objects present in a
PCEP Path Computation request (PCReq) message (see
[I-D.ietf-pce-pcep]). Several metrics may be requested that are
specified by a set of objects defined in section Section 4. Note
that this set of objects is by all means not limitative and may be
extended in further revision of this document. The most simplest
form of metric is PCE liveness.
Vasseur Expires April 13, 2007 [Page 5]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
For the sake of illustraion, consider the two following examples:
Example 1: PCC1 requests to check the path computation chain should a
path computation be requested for a specific TE LSP named T1. A
PCMonReq message is sent that contains a MONITORING object specifying
a path computation check, along with the appropriate set of objects
(e.g. RP, END-POINTS, ...) that would be included in a PCReq message
for T1.
Example 2: PCC1 request to gather the processing time along the path
computation chain selected for the computation of T1. In addition to
the objects listed in example 1, the PCMonReq message also contain
the PROC-TIME object defined in section Section 4.1.
Example 3: PCC2 request to gather performance metrics along the
specific path computation chain <pce1, pce2, pce3, pce7>. A PCMonreq
message is sent to PCE1 that contains a set of PCE-ID objects that
identify PCE1, PCE2, PCE3 and PCE7 respectively.
3.2. Path Monitoring Reply message (PCMonRep)
The Message-Type field of the PCEP common header for the PCMonRep
message is set to 9 (To be confirmed by IANA).
There is one mandatory objects that MUST be included within a
PCMonRep message: the Monitoring object (see sectionSection 4.1). If
the Monitoring object is missing, the receiving PCE MUST send an
error message to the requesting PCC. Other objects are optional.
The format of a PCReq message is as follows:
<PCMonRep Message>::= <Common Header>
<MONITORING>
[<RP>]
[<metric-pce-list>]
where:
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=[<PCE-ID>]
[<PROC-TIME>]
[<TIME-STAMP>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD-
BALANCING objects are defined in [I-D.ietf-pce-pcep].
Vasseur Expires April 13, 2007 [Page 6]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
4. Path Computation Monitoring Objects
Each new PCEP object defined in the document is compliant to the PCEP
object format defined in [I-D.ietf-pce-pcep], with the P flag and the
I flag cleared since these flags are exclusively related to path
computation request.
4.1. MONITORING Object
The MONITORING object MUST be carried within each PCMonReq and
PCMonRep messages. The MONITORING object is used to specify the set
of requested performance metrics.
The MONITORING Object-Class is to be assigned by IANA (recommended
value=16)
The MONITORING Object-Type is to be assigned by IANA (recommended
value=1)
The format of the MONITORING 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |I|P|R|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| monitoring-id-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 18 bits - The following flags are currently defined:
C (Check) - 1 bit: when set, this indicates that the performance
metric of interest is the PCE's availability.
R (Record) - 1 bit: when set, this indicates that the PCE's
indentifier MUST be included in the corresponding PCMonRep message in
the form of a PCE-ID object.
P (Processing Time) - 1 bit: the P bit of the MONITORING object
carried in a PCMonReq message is set to indicate that the processing
times is a metric of interest, in which case a PROC-TIME object MUST
be inserted in the corresponding PCMonRep message. The P bit MUST
always be set in a PCMonRep message if also set in the corresponding
PCMonReq message.
Vasseur Expires April 13, 2007 [Page 7]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
I (Incomplete) - 1 bit: the I bit MUST be set by a PCE that supports
the PCMonReq message, which does not trigger any policy violation but
that cannot provide the set of required performance metrics for
unspecified reasons. Once set, the I bit MUST NOT be changed by a
receiving PCE.
Monitoring-id-number (32 bits). The monitoring-id-number value
combined with the source IP address of the PCC and the PCE address
uniquely identify the monitoring request context. The monitoring-id-
number MUST be incremented each time a new monitoring is sent to a
PCE. The value 0x0000000 is considered as invalid. If no reply to a
monitoring request is received from the PCE, and the PCC wishes to
resend its path computation monitoring request, the same monitoring-
id-number MUST be used. Conversely, different monitoring-id-number
MUST be used for different requests sent to a PCE. The same
monitoring-id-number may be used for path computation monitoring
requests sent to different PCEs. The path computation monitoring
reply is unambiguously identified by the IP source address of the
replying PCE.
No optional TLVs are currently defined.
4.2. PCE-ID Object
The PCE-ID Object is used in a PCMonReq message to record the IP
address of the PCE for which performance metrics are collected and in
a PCMonRep message to record the IP address of the PCE reporting
performance metrics.
The PCE-ID Object-Class is to be assigned by IANA (recommended
value=17)
The PCE-ID Object-Type is to be assigned by IANA (recommended
value=1)
The format of the PCE-ID Object is as follows:
Vasseur Expires April 13, 2007 [Page 8]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Lenght |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE IP Address //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address-type: 1 IPv4 2 IPv6
Length 4 (IPv4) or 16 (IPv6)
PCE IP Address: The PCE IP address. It is RECOMMENDED to use the
same IP address as the address used in the PCE-ADDRESS sub-TLV
defined in [I-D.ietf-pce-disco-proto-ospf] and
[I-D.ietf-pce-disco-proto-isis]should a dynamic discovery mechanism
be used for PCE discovery.
4.3. PROC-TIME Object
The PROC-TIME object MUST be present within a PCMonRep message if the
P bit of the MONITORING object carried within the corresponding
PCMonReq was set. The PROC-TIME object is used to report various
processing time related metrics. The Current-processing-time field
is used to report the processing time for a particular request the
characteristics of which are specified in the corresponding PCMonReq
message. By constrast, a PCC may request processing time metrics
that are not related to a particular request, in which case the
request is qualified as a "general" request. For example, the PCC
may want to know the minimum, maximum, average and maximum processing
times on a particular PCE. The algorithm(s) used by a PCE to compute
such metrics are out of the scope of this document but a flag is
specified that is used to indicate to the requester whether the
processing time values were estimated or computed. For example, if
the processing time for a specific TE LSP computation is requested,
the PCE may either (1) estimate without performing an actual path
computation or (2) effectively perform the computation to report the
processing time.
Furthermore, the same object can be used to report the processing
time for a particular request in addition to the general processing
times computed for all request over a period of time.
The PROC-TIME Object-Class is to be assigned by IANA (recommended
value=18)
Vasseur Expires April 13, 2007 [Page 9]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
The PROC-TIME Object-Type is to be assigned by IANA (recommended
value=1)
The format of the PROC-TIME 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current-processing-time |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-processing-time |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-processing-time |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average-processing time |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variance-processing-time |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 18 bits - No Flags are currently defined:
E (Estimated) - 1 bit: when set, this indicates that the reported
metric value is based on estimated processing time as opposed to
actual computation(s).
Current-processing-time: This field indicates in milliseconds the
processing time for the path computation of interest characterized in
the corresponding PCMonReq message and MUST be set to 0x00000000 if
the request is a general request (does not relate to a particular
path computation request).
Min-processing-time: This field indicates in milliseconds the minimum
processing time. The equation/algorithm used to compute this value
is implementation specific and outside of the scope of this document
(A PCE may decide to compute the minimum processing time over a
period of times, for the last N path computation requests, ...). If
the G flag of the MONITORING object if cleared then this field MUST
be set to 0x00000000.
Max-processing-time: This field indicates in milliseconds the maximum
processing time. The equation/algorithm used to compute this value
is implementation specific and outside of the scope of this document
(A PCE may decide to compute the minimum processing time over a
period of times, for the last N path computation requests, ...). If
the G flag of the MONITORING object if cleared then this field MUST
be set to 0x00000000.
Vasseur Expires April 13, 2007 [Page 10]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
Average-processing-time: This field indicates in milliseconds the
average processing time. The equation/algorithm used to compute this
value is implementation specific and outside of the scope of this
document (A PCE may decide to compute the minimum processing time
over a period of times, for the last N path computation requests,
...). If the G flag of the MONITORING object if cleared then this
field MUST be set to 0x00000000.
Variance-processing-time: This field indicates in milliseconds the
variance of the processing times. The equation/algorithm used to
compute this value is implementation specific and outside of the
scope of this document (A PCE may decide to compute the minimum
processing time over a period of times, for the last N path
computation requests, ...). If the G flag of the MONITORING object
if cleared then this field MUST be set to 0x00000000.
More granularity may be introduced in further revision of this
document to get a monitoring metric for a general request of a
particular class (e.g. all PCReq of priority X).
4.4. TIMESTAMP Object
A TIMESTAMP object will be specified in a further revision of this
document that could be used to provide indication on the time at
which a PCMonReq message has been received by a PCE and the time at
which the PCMonReq message has been relayed to the next-hop PCE or
the time at which a PCMonRep message has been sent to the requester.
5. Multi-destination monitoring
In a further revision of this document, a new object will be
specified allowing a PCC or a user to gather performance metrics for
a set of destinations using a single PCMonReq message. For example,
using a single PCMonreq message originated by the PCC, performance
metrics for the set of path computation chains involved in the
computation of a set of TE LSPs will be gathered. Such set of
destinations could be specified in the form of a subnets.
6. Policy
The receipt of a PCMonReq message may trigger a policy violation on
some PCE in which case the PCE MUST send a PCErr message with Error-
Type=12 and Error-value=1.
Vasseur Expires April 13, 2007 [Page 11]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
7. Element of procedure
Reception of a PCMonReq message: upon receiving a PCMonReq message,
if the PCE does not support the PCMonReq message, the PCE MUST send a
PCErr message with Error-type=11 and Error-value=1
If the PCE supports the PCMonReq message but the request is
prohibited by policy, the PCE MUST send a PCErr message with Error-
Type=12 and Error-value=1.
If the PCE supports the PCMonReq and the request is not prohibited by
policy, the receiving PCE MUST first determine whether it is the last
PCE of the path computation chain the process of which is being
outside of this document. If the PCE is not the last element of the
path computation chain, the PCMonReq message is relayed to the next
hop PCE: such next-hop may either be specified by means of a PCE-ID
object present in the PCMonReq message or dynamically determined by
means of a procedure outside of the scope of this document.
Conversely, if the PCE is the last PCE of the path computation chain,
the PCE originates a PCMonRep message that contains the requested
objects according to the set of requested performance metrics listed
in the MONITORING object carried in the corresponding PCMonReq
message.
Reception of a PCMonRep message: upon receiving a PCMonRep message,
the PCE processes the request, adds the relevant objects to the
PCMonRep message and forwards the PCMonRep message to the upstream
requesting PCE or PCC.
Special case of Multi-destination monitoring: performance monitoring
request related to more than one destinations may lead to involve a
set of path computation chains. In that case, a PCE sends each copy
of the PCMonReq message to each downstream PCE of each path
computation chain.
8. Manageability Considerations
To be addressed in a further revision of this document.
9. To be considered in a further revision of this document
IT might be desirable to modify the format of the PCMonReq and
PCMonRep messages to support the bundling of multiple performance
metrics collection for a set of TE LSPs.
Vasseur Expires April 13, 2007 [Page 12]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
10. IANA Considerations
Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined
in this document:
Value Meaning
8 Path Computation Monitoring Request (PCMonReq)
9 Path Computation Monitoring Reply (PCMonRep)
The following new PCEP objects are defined in this document.
Object-Class Name
16 MONITORING
Object-Type
1
17 PCE-ID
Object-Type
1
18 PROC-TIME
Object-Type
1
Two new error types are defined in this document (Error-Type and
Error-value to be assigned by IANA).
Error-type Meaning
11 Performance Monitoring not supported
Error-value
1: Monitoring message not supported by one
or PCEs along the domain path
12 Performance Monitoring Policy violation
1: Monitoring message supported but rejected
due to policy violation
11. Security Considerations
To be addressed in a further revision of this document.
12. Acknowledgements
Vasseur Expires April 13, 2007 [Page 13]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
13. References
13.1. Normative References
[I-D.ietf-pce-pcep]
Vasseur, J., "Path Computation Element (PCE) communication
Protocol (PCEP) - Version 1", draft-ietf-pce-pcep-02 (work
in progress), June 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
13.2. Informative References
[I-D.ietf-pce-brpc]
Vasseur, J., "A Backward Recursive PCE-based Computation
(BRPC) procedure to compute shortest inter-domain Traffic
Engineering Label Switched Paths", draft-ietf-pce-brpc-00
(work in progress), August 2006.
[I-D.ietf-pce-disco-proto-isis]
Roux, J., "IS-IS protocol extensions for Path Computation
Element (PCE) Discovery",
draft-ietf-pce-disco-proto-isis-00 (work in progress),
September 2006.
[I-D.ietf-pce-disco-proto-ospf]
Roux, J., "OSPF protocol extensions for Path Computation
Element (PCE) Discovery",
draft-ietf-pce-disco-proto-ospf-00 (work in progress),
September 2006.
Author's Address
JP Vasseur
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Vasseur Expires April 13, 2007 [Page 14]
Internet-Draft draft-vasseur-pce-monitoring-00.txt October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Vasseur Expires April 13, 2007 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 19:25:27 |