PCE Working Group D. Dhody
Internet-Draft U. Palle
Intended status: Standard Huawei Technologies India Pvt Ltd
Expires: December 31, 2011 June 29, 2011
Encoding of Data Structure (DS) in the Path Computation Element
Communication Protocol (PCEP)
draft-dhody-pce-pcep-ds-00
Abstract
The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains has been
identified as a key requirement for P2P and P2MP scenarios.
Backward-Recursive PCE-Based Computation (BRPC) [RFC 5441] defines
VSPT [Virtual Shortest Path Tree] as a default de-facto data
structure for PCRep message in inter-domain scenarios.
This document defines extensions to the PCE communication Protocol
(PCEP) to allow multiple data structures. Extensions are defined for
PCE to indicate the set of Data Structure (DS) it supports; also PCC/
PCE can indicate in a path computation request the required DS, and a
PCE can report in a path computation reply the Data Structure that
was used in the path reply message.
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.
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 December 31, 2011.
Dhody & Palle Expires December 31, 2011 [Page 1]
Internet-Draft DS June 2011
Copyright Notice
Copyright (c) 2010 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
(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 Simplified BSD License.
This Internet-Draft will expire on December 31, 2011.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Need for multiple Data Structure . . . . . . . . . . . . . . . 4
4. Discovery of PCE Data Structure . . . . . . . . . . . . . . . 5
4.1. DS-List TLV . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 6
5. Data Structure in PCEP Path Computation Request and Reply
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. DS Object . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Elements of Procedure . . . . . . . . . . . . . . . . 7
5.2. Carrying The DS Object In a PCEP Message . . . . . . . . . 9
5.3. New RP Object Flag . . . . . . . . . . . . . . . . . . . . 11
5.3.1. Elements of Procedure . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. PCE Data Structure Sub-Registry . . . . . . . . . . . . . 12
6.2. PCEP Code Points . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. DS Object . . . . . . . . . . . . . . . . . . . . . . 12
6.2.2. DS-List TLV . . . . . . . . . . . . . . . . . . . . . 12
6.2.3. PCEP Error Values . . . . . . . . . . . . . . . . . . 13
6.2.4. RP Object Flag . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Manageability Considerations . . . . . . . . . . . . . . . . . 14
8.1. Control of Function and Policy . . . . . . . . . . . . . . 14
8.2. Information and Data Models . . . . . . . . . . . . . . . 14
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 14
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 15
8.6. Impact On Network Operations . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Dhody & Palle Expires December 31, 2011 [Page 2]
Internet-Draft DS June 2011
1. Introduction
The Path Computation Element (PCE) architecture is defined in
[RFC4655]. [RFC 5441] describe a PCE-based path computation
procedure to compute optimal inter-domain constrained (G)MPLS TE
LSPs. It also defines VSPT [Virtual Shortest Path Tree] which is the
only data structure and is used in all inter-domain scenarios.
This document describes the need for multiple data structure (DS).
It may be useful for a PCC/PCE to discover the set of Data Structure
(DS) supported by a PCE. Furthermore, PCC/PCE requires the ability
to indicate in a path computation request a required/desired Data
Structure, as well as optional function parameters.
For these purposes, this document extends the PCE communication
Protocol (PCEP). It defines PCEP extensions that allow a PCE to
advertise a list of supported Data Structure (DS), as well as
extensions to carry Data Structure (DS) in PCEP request and reply
messages. It complements the PCEP base specification [RFC5440].
Note that OSPF- and IS-IS-based PCE discovery mechanisms are defined
in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the
discovery of a few generic parameters, while more detailed PCE
parameters should be discovered using the PCE communication Protocol.
Data Structure (DS) are in this second category; thus, the Data
Structure discovery procedure is handled by PCEP.
A new PCEP TLV, named the DS-List TLV, is defined in Section 4. The
DS-List TLV is carried in the PCEP OPEN object and allows a PCE to
list, during PCEP session-setup phase, the Data Structure (DS) that
it supports.
A new PCEP object, the DS object, is defined in Section 5. The DS
object is carried within a PCReq (Path Computation Request) message
to indicate the required/desired data structure to be applied by a
PCE, or in a PCRep (Path Computation Reply) message to indicate the
data structure that was used for path computation and the reply
message.
1.1. 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 RFC2119.
Dhody & Palle Expires December 31, 2011 [Page 3]
Internet-Draft DS June 2011
2. Terminology
The following terminology is used in this document.
BRPC: Backward Recursive Path Computation.
DS: Data Structure.
H-PCE: Hierarchical PCE.
IGP: Interior Gateway Protocol. Either of the two routing
protocols, Open Shortest Path First (OSPF) or Intermediate System
to Intermediate System (IS-IS).
IS-IS: Intermediate System to Intermediate System.
OF: Objective Function.
OSPF: Open Shortest Path First.
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
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.
P2MP: Point-to-Multipoint
P2P: Point-to-Point
TE LSP: Traffic Engineering Label Switched Path.
TLV: Type-Length-Variable data encoding.
VSPT: Virtual Shortest Path Tree as defined in [RFC 5441].
3. Need for multiple Data Structure
o [PCE-P2MP-PROCEDURES] describes the need for an extended VSPT for
computation of the best core-tree.
o [RFC 6007] describes the need for disjoint VSPT in case of
Synchronized Dependent Path Computations.
o VSPT does not fit into hierarchical PCE paradigm described in
[PCE-HIERARCHY-FWK].
Dhody & Palle Expires December 31, 2011 [Page 4]
Internet-Draft DS June 2011
o VSPT does not work well with constraints like HOP-LIMIT.
o Since PCEP allow multiple Objective Function (OF); it is natural
to extend PCEP to support multiple Data Structure based on path
computation scenario
4. Discovery of PCE Data Structure
This section defines PCEP extensions (see [RFC5440]) so as to support
the advertisement of the Data Structure (DS) supported by a PCE.
A new PCEP DS-List (Data Structure list) TLV is defined. The PCEP
DS-List TLV is carried within an OPEN object. This way, during PCEP
session-setup phase, a PCE can advertise to a PCEP peer the list of
data structure it supports.
4.1. DS-List TLV
The PCEP DS-List TLV is optional. It MAY be carried within an OPEN
object sent by a PCE in an Open message to a PCEP peer so as to
indicate the list of supported data structures.
The DS-List TLV format is compliant with the PCEP TLV format defined
in [RFC5440]. That is, the TLV is composed of 2 octets for the type,
2 octets specifying the TLV length, and a Value field. The Length
field defines the length of the value portion in octets. The TLV is
padded to 4-octet alignment, and padding is not included in the
Length field (e.g., a 3-octet value would have a length of three, but
the total size of the TLV would be eight octets).
Dhody & Palle Expires December 31, 2011 [Page 5]
Internet-Draft DS June 2011
The PCEP DS-List TLV has the following format:
TYPE: 4
LENGTH: N * 2 (where N is the number of Data Structures)
VALUE: list of 2-byte data structure code points, identifying the
data structures supported by the sender of the Open message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Code #1 | DS Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DS Code (2 bytes): Data Structure code point identifier. IANA
manages the "PCE Data Structure" code point registry
(see Section 6).
4.2. Elements of Procedure
A PCE MAY include a DS-List TLV within an OPEN object in an Open
message sent to a PCEP peer in order to advertise a set of one or
more supported Data Structures. The DS-List TLV MUST NOT appear more
than once in an OPEN object. If it appears more than once, the PCEP
session MUST be rejected with error type 1 and error value 1 (PCEP
session establishment failure / Reception of an invalid Open
message). The absence of the DS-List TLV in an OPEN object MUST be
interpreted as an absence of information on the list of supported
data structures by the PCE, default data stricture VSPT is always
supported.
As specified in [RFC5440], a PCEP peer that does not recognize the
DS-List TLV will silently ignore it.
5. Data Structure in PCEP Path Computation Request and Reply Messages
This section defines PCEP extensions [RFC5440] so as to support the
communication of Data Structure (DS) in PCEP path computation request
and reply messages. A new PCEP DS (Data Structure) object is
defined, to be carried within a PCReq message in order for the PCC/
PCE to indicate the required/desired data structure.
The PCEP DS object may also be carried within a PCRep message in
order for the PCE to indicate the data structure that was used by the
PCE and used in the reply message.
Dhody & Palle Expires December 31, 2011 [Page 6]
Internet-Draft DS June 2011
A new flag is defined in the RP (Request Parameters) object. The
flag is used in a PCReq message to indicate that the PCE MUST include
a DS object in the PCRep message to indicate the data structure that
was used during path computation and encoded in the reply message.
Also, new PCEP error types and values are defined.
5.1. DS Object
The PCEP DS (Data Structure) object is optional. It MAY be carried
within a PCReq message so as to indicate the desired/required data
structure to be applied by the PCE during path computation or within
a PCRep message so as to indicate the data structure that was used by
the PCE during path computation and in the reply message.
The DS object format is compliant with the PCEP object format
defined in [RFC5440].
The DS Object-Class is <TBA by IANA>.
The DS Object-Type is 1.
The format of the DS object body is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DS Code (2 bytes): The identifier of the Data Structure. IANA
manages the "PCE Data Structure" code point registry
Reserved (2 bytes): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Optional TLVs may be defined in the future.
5.1.1. Elements of Procedure
To request the use of a specific data structure by the PCE, a PCC/PCE
includes a DS object in the PCReq message.
[RFC5440] specifies a bit flag, referred to as the P bit, carried in
Dhody & Palle Expires December 31, 2011 [Page 7]
Internet-Draft DS June 2011
the common PCEP object header. The P bit is set by a PCC/PCE to
mandate that a PCE must take the information carried in the object
into account during the path computation.
If the P bit is set in the DS object, the data structure is mandatory
(required data structure) and the PCE MUST use the data structure
during path computation. If the P bit is clear in the DS object, the
data structure is optional (desired data structure) and the PCE
SHOULD apply the data structure if it is supported but MAY choose to
apply a different data structure, according to local capabilities and
policies.
On receipt of a PCReq message with a DS object, a PCE MUST proceed as
follows:
o If the DS object is unknown/unsupported, the PCE MUST follow
procedures defined in [RFC5440]. That is, if the P bit is set,
the PCE sends a PCErr message with error type 3 or 4 (Unknown /
Not supported object) and error value 1 or 2 (unknown /
unsupported object class / object type), and the related path
computation request MUST be discarded. If the P bit is cleared,
the PCE is free to ignore the object.
o If the data structure is unknown/unsupported and the P bit is set,
the PCE MUST send a PCErr message with error type 3 or 4 (Unknown
/ Not supported object) and error value 4 (Unrecognized/
Unsupported parameter), and the related path computation request
MUST be discarded.
o If the data structure is unknown/unsupported and the P bit is
cleared, the PCE SHOULD apply another (default) data structure.
o If the data structure is supported but policy does not permit
applying it and if the P bit is set, the PCE MUST send a PCErr
message with the PCEP error type "policy-violation" (type 5) and a
new error value, "data structure not allowed", which is defined in
this document.
o If the data structure is supported but policy does not allow
applying it and if the P bit is cleared, the PCE SHOULD apply
another (default) data structure.
o If the data structure is supported and policy allows applying it
and if the P bit is set, the PCE MUST apply the requested data
structure. Otherwise, if the P bit is cleared, the PCE is free to
apply any other data structure.
The default data structure is VSPT or may be locally configured.
Dhody & Palle Expires December 31, 2011 [Page 8]
Internet-Draft DS June 2011
5.2. Carrying The DS Object In a PCEP Message
The DS object MAY be carried within a PCReq message. If a data
structure is to be applied to a set of synchronized path computation
requests, the DS object MUST be carried just after the corresponding
SVEC (Synchronization VECtor) object and MUST NOT be repeated for
each elementary request.
A DS object specifying a data structure that applies to an individual
path computation request (non-synchronized case) MUST follow the RP
object for which it applies.
The format of the PCReq message is updated as follows.
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<DS>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<DS>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
<metric-list> ::= <METRIC>[<metric-list>]
The DS object MAY be carried within a PCRep message to indicate the
data structure used by the PCE during path computation and in the
reply message.
When the PCE wants to indicate to the PCC/PCE the data structure that
was used for the synchronized computation of a set of paths, the
PCRep message MUST include the corresponding SVEC object directly
Dhody & Palle Expires December 31, 2011 [Page 9]
Internet-Draft DS June 2011
followed by the DS object, which MUST NOT be repeated for each
elementary request.
A DS object specifying a data structure used for an individual path
computation (non-synchronized case) MUST follow the RP object for
which it applies.
The format of the PCRep message is updated as follows.
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<DS>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
and where:
<attribute-list> ::= [<OF>]
[<DS>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC> [<metric-list>]
Note: The DS object MAY be associated to a negative reply, i.e., a
reply with a NO-PATH object.
Dhody & Palle Expires December 31, 2011 [Page 10]
Internet-Draft DS June 2011
5.3. New RP Object Flag
In some cases, where no data structure is specified in the request or
an optional data structure is desired (P flag cleared in the DS
object common header) but the PCE does not follow the request, the
PCC/PCE may desire to know the data structure that was used by the
PCE during path computation. To that end, a new flag is defined in
the RP object, named the DS flag, allowing a PCC/PCE to request for
the inclusion in the path computation reply of the data structure
that was used by the PCE during path computation.
The following new bit flag of the RP object is defined: The Supply DS
on response flag (bit number <TBA>). When set in a PCReq message,
this indicates that the PCE MUST provide the applied data structure
in the PCRep message. When set in a PCRep message, this indicates
that the data structure that was used during path computation is
included.
5.3.1. Elements of Procedure
If the PCC/PCE wants to know the data structure used by the PCE
during path computation for a given request, it sets the DS flag in
the RP object.
On receipt of a PCReq message with the DS flag in the RP object set,
the PCE proceeds as follows:
o If policy permits, it MUST include in the PCRep message a DS
object indicating the data structure it used during path
computation.
o If policy does not permit, it MUST send a PCErr message with the
PCEP error code "policy-violation" (type 5) and a new error value,
"data structure indication not allowed", which is defined in this
document.
Note that a legacy PCE might not recognize the DS flag in the RP
object. According to the definition of the Flags field for the RP
object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the
unknown flag, resulting in it sending a PCRep that does not contain a
DS object. In this case, the PCC/PCE's behavior is an implementation
choice. It might:
o Discard the PCRep because it really wanted the DS object returned.
o Accept the PCRep without the knowledge of the DS that was applied.
Note also that these procedures can give rise to the situation where
Dhody & Palle Expires December 31, 2011 [Page 11]
Internet-Draft DS June 2011
a PCC/PCE receives a PCRep that contains a DS object with a data
structure identifier that the PCC/PCE does not recognize. In this
situation, the PCC/PCE behavior is dependent on implementation and
configuration. The PCC/PCE could choose any of the following (or
some other action):
o Ignore the DS object and use the computed path.
o Add the data structure to its view of the PCE's repertoire for
inclusion in future computation requests.
o Discard the PCRep (i.e., the computed path) and send a PCReq to
another PCE.
o Discard the PCRep (i.e., the computed path) and send another PCReq
to the same PCE explicitly requiring the use of some other data
structure (i.e., by setting the P bit in the DS object).
6. IANA Considerations
6.1. PCE Data Structure Sub-Registry
This document defines a 16-bit PCE data structure identifier to be
carried within the PCEP DS object, and also defines the PCEP DS-List
TLV. IANA should create and manages the 16-bit "PCE Data Structure"
code point registry. Values are TBD.
6.2. PCEP Code Points
6.2.1. DS Object
IANA manages the PCEP Objects code point registry (see [RFC5440]).
This is maintained as the "PCEP Objects" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry. This document
defines a new PCEP object, the DS object, to be carried in PCReq and
PCRep messages.
IANA should make the following allocation:
Object Name Object Name Reference
Class Type
------------------------------------------------------------
TBA DS 1 Data Structure This Doc
6.2.2. DS-List TLV
IANA manages the PCEP TLV code point registry (see [RFC5440]). This
is maintained as the "PCEP TLV Type Indicators" sub-registry of the
Dhody & Palle Expires December 31, 2011 [Page 12]
Internet-Draft DS June 2011
"Path Computation Element Protocol (PCEP) Numbers" registry. This
document defines a new PCEP TLV, the DS-List TLV, to be carried in
the OPEN object.
IANA should make the following allocation:
Type TLV name References
-----------------------------------------------
TBA DS-List This Doc
6.2.3. PCEP Error Values
IANA maintains a registry of Error-types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error
Types and Values" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
Two new Error-values are defined for the Error-type "policy
violation" (type 5):
Error-type Meaning and error values Reference
------------------------------------------------------------------
5 Policy violation
Error-value=TBA: data structure not This Doc
allowed (request rejected)
Error-value=TBA: DS bit of the RP This Doc
object set (request rejected)
6.2.4. RP Object Flag
A new flag of the RP object (specified in [RFC5440]) is defined in
this document. IANA maintains a registry of RP object flags in the
"RP Object Flag Field" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
IANA should make the following allocation:
Bit Description Reference
----------------------------------------------
TBA Supply DS on response This Doc
7. Security Considerations
PCEP security mechanisms are described in [RFC5440] and are used to
secure entire PCEP messages. Nothing in this document changes the
message flows or introduces any new messages, so the security
Dhody & Palle Expires December 31, 2011 [Page 13]
Internet-Draft DS June 2011
mechanisms set out in [RFC5440] continue to be applicable.
This document introduces a single new object that may optionally be
carried on PCEP messages and will be automatically secured using the
mechanisms described in [RFC5440].
If a PCEP message is vulnerable to attack (for example, because the
security mechanisms are not used), then the DS object could be used
as part of an attack; however, it is likely that other objects will
provide far more significant ways of attacking a PCE or PCC in this
case.
8. Manageability Considerations
8.1. Control of Function and Policy
It MUST be possible to configure the activation/deactivation of data
structure discovery in PCEP. In addition to the parameters already
listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD
allow configuring a list of authorized data structure on a PCE. This
may apply to any session the PCEP speaker participates in, to a
specific session with a given PCEP peer, or to a specific group of
sessions with a specific group of PCEP peers. Note that it is not
mandatory for an implementation to support all data structure
defined. It MUST be possible to configure a default data structure
used for path computation when a path request is received that
requests to use an optional data structure.
8.2. Information and Data Models
The PCEP MIB Module defined in [PCEP-MIB] could be extended to
include data structure.
8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
8.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440].
Dhody & Palle Expires December 31, 2011 [Page 14]
Internet-Draft DS June 2011
8.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any requirements on
other protocols in addition to those already listed in [RFC5440].
8.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440].
9. Acknowledgments
We would like to thank Pradeep Shastry, Suresh babu, Quintin Zhao and
Chen Huaimo for their useful comments and suggestions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", March 1997.
10.2. Informative References
[PCE-HIERARCHY-FWK] King, D. and A. Farrel, "The Application of
the Path Computation Element Architecture to
the Determination of a Sequence of Domains in
MPLS and GMPLS", September 2010.
[PCE-P2MP-PROCEDURES] Zhao, Q., Ali, Z., Saad,, T., and D. King,
"PCE-based Computation Procedure To Compute
Shortest Constrained P2MP Inter-domain Traffic
Engineering Label Switched Paths",
January 2011.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture",
August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", September 2006.
[RFC4674] Le Roux, J., "Requirements for Path
Computation Element (PCE) Discovery",
October 2006.
[RFC5088] Le Roux, J., Vasseur, JP., Ikejiri, Y., and R.
Dhody & Palle Expires December 31, 2011 [Page 15]
Internet-Draft DS June 2011
Zhang, "OSPF Protocol Extensions for Path
Computation Element (PCE) Discovery",
January 2008.
[RFC5089] Le Roux, J., Vasseur, JP., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path
Computation Element (PCE) Discovery",
January 2008.
[RFC5440] Ayyangar, A ., Farrel, A ., Oki, E., Atlas,
A., Dolganow, A., Ikejiri, Y., Kumaki, K.,
Vasseur, J., and J. Roux, "Path Computation
Element (PCE) communication Protocol (PCEP)",
March 2009.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le
Roux, "A Backward-Recursive PCE-Based
Computation (BRPC) Procedure to Compute
Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", April 2009.
[RFC5541] Le Roux, J., Vasseur, JP., and Y. Ikejiri,
"Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)", June 2009.
[RFC6007] Nishioka, I. and D. King, "Use of the
Synchronization VECtor (SVEC) List for
Synchronized Dependent Path Computations)",
September 2010.
Authors' Addresses
Dhruv Dhody
Huawei Technologies India Pvt Ltd
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruvd@huawei.com
Dhody & Palle Expires December 31, 2011 [Page 16]
Internet-Draft DS June 2011
Udayasree Palle
Huawei Technologies India Pvt Ltd
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasreepalle@huawei.com
Dhody & Palle Expires December 31, 2011 [Page 17]
Internet-Draft DS June 2011