| PCE Working Group | R. Casellas, Ed. |
| Internet-Draft | CTTC |
| Intended status: Best Current Practice | O. Gonzalez de Dios, Ed. |
| Expires: April 29, 2015 | Telefónica I+D |
| A. Farrel, Ed. | |
| Old Dog Consulting | |
| C. Margaria | |
| Juniper Networks | |
| D. Dhody | |
| X. Zhang | |
| Huawei Technologies | |
| October 26, 2014 |
PCEP Best Current Practices - Message formats and extensions
draft-many-pce-pcep-bcp-01
A core standards track RFC defines the main underlying mechanisms, basic object format and message structure of the Path Computation Element (PCE) Communications Protocol (PCEP). PCEP has been later extended in several RFCs, focusing on specific functionalities. The proliferation of such companion RFCs may cause ambiguity when implementing a PCE based solution. This document aims at documenting best current practices and at providing a reference RBNF grammar for PCEP messages, including object ordering and precedence rules.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 29, 2015.
Copyright (c) 2014 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.
The RBNF notation, defined in [RFC5511], is used to specify the message format for the Path Computation Element communication Protocol (PCEP). The core of PCEP has been defined in [RFC5440] and later extended, notably, in [RFC7150] to support Vendor Extensions; in [RFC5455], adding a CLASSTYPE object to support Diffserv-aware Traffic Engineering (DS-TE); in [RFC5520], for topology confidentiality by means of Path-Keys; in [RFC5521], in support of exclusions; in [RFC5541] to convey specific Objective Functions; in [RFC5557], for Global Concurrent Optimization, in [RFC5886], for monitoring and in [RFC6006] for point-to-multipoint (P2MP) computation.
At the time of writing, several I.-D. are also addressing specific aspects, such as PCEP extensions for GMPLS networks [I-D.ietf-pce-gmpls-pcep-extensions], for hierarchical PCE [I-D.ietf-pce-hierarchy-extensions] or for multi-layer, multi-region networks [I-D.ietf-pce-inter-layer-ext]. Stateful PCE capabilites are also being defined in [I-D.ietf-pce-stateful-pce], including the case where a PCE is able to initiate the establishment and release of LSPs in [I-D.ietf-pce-pce-initiated-lsp].
Most PCEP RFCs describe specific protocol extensions and, as such, they focus on their constructs extending some base RFCs. Although it is not the intention of each individual draft or RFC to provide the latest and most complete/full definition of the protocol messages, in practice combining all the extensions as defined in the respective RFCs is complex, and open to interpretation.
Message rules are sometimes provided within the text, resulting in ambiguity. Moreover, the fact that extensions may be defined in parallel may be a problem. The canonical example is the case where RFC X defines construct p ::= A and subsequent RFC Y extends RFC X stating that object C MUST follow object A and RFC Z also extends RFC X stating that object D MUST follow object A.
This document describes current practice when implementing existing PCEP RFCs. This involves extending the existing RBNF notations using more verbose constructs where appropiate, while being semantically equivalent, in order to avoid ambiguity and to facilitate message validation.
The use of RBNF [RFC5511] states that the ordering of objects and constructs in an assignment is explicit, and protocol specifications MAY opt to state that ordering is only RECOMMENDED (the elements of a list of objects and constructs MAY be received in any order).
The core PCEP document [RFC5440] states in Section 6 that an implementation MUST form the PCEP messages using the object ordering specified in [RFC5440].
[RFC5886] equally states that "An implementation MUST form the PCEP messages using the object ordering specified in this document."
[RFC5521] only states that "the XRO is OPTIONAL and MAY be carried within Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages." and no ordering is provided. For example, it does not mention SVEC objects or rules.
[RFC5541] specifies that "the OF object MAY be carried within a PCReq message. If an objective function is to be applied to a set of synchronized path computation requests, the OF object MUST be carried just after the corresponding SVEC (Synchronization VECtor) object and MUST NOT be repeated for each elementary request. Similarly, if a metric is to be applied to a set of synchronized requests, the METRIC object MUST follow the SVEC object and MUST NOT be repeated for each elementary request. (...) An OF object specifying an objective function that applies to an individual path computation request (non-synchronized case) MUST follow the RP object for which it applies". It should be understood that this last sentence introduces ambiguity and if interpreted as the OF object MUST strictly follow (right after) the RP object, it contradicts [RFC5440] where the RP object is followed by the ENDPOINTS object.
RFCs that extend the core PCEP protocol are not consistent with the object ordering.
[RFC5541] in section 3.2 is not consistent with the ordering of OF and metric-list:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
<request> ::= <RP>
(snip)
[<metric-list>]
[<OF>]
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
In view of the above considerations, this document aims at providing an object ordering for PCEP messages so implementations can interoperate.
PCEP RFCs may use inconsistent or ambiguous naming. For example [RFC5440] defines the Open message as having a common header and an OPEN object, and later uses Open to refer to the object that may appear in a PCErr message.
<Open Message> ::= <Common Header>
<OPEN>
<PCErr Message> ::= <Common Header>
(<error-obj-list> [<Open>]) | <error>
[<error-list>]
It is common that a sequence or repetition of an object OBJ is noted as obj-list. It may happen that in extensions to core documents, the naming is kept although it no longer applies to such a sequence. For example, [RFC5886] states:
<svec-list> ::= <SVEC>
[<OF>]
[<svec-list>]
and later
<svec-list> ::= <SVEC>
[<svec-list>]
The current RBNF notation does not capture the semantics/intent of the messages; notably, when two options are mutually exclusive and at least one is mandatory. In most cases, this is noted as both options being optional. For example [RFC5440] states:
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
with this example, a message that contains a response of the form <RP><NO-PATH><ERO><..> (that is, a NO-PATH object followed by a path) is correct and successfully parsed. Likewise, a response with just an RP object is valid. Although the actual text within the RFC may state the intention and disambiguate the grammar, the RBNF notation can be improved to better capture the semantics, message structure and original intent. Such enhancements allow the automated validation of message elements.
Similarly, if the intent is to specific a rule such as metric-pce which includes a PCE-ID object followed by a PROC-TIME object and/or an OVERLOAD object, the syntax:
<metric-pce> ::= <PCE-ID> [<PROC-TIME>] [<OVERLOAD>]
allows, amongst other combinations, that neither PROC-TIME nor OVERLOAD appears, which is not the intended behavior (there should be at least one metric). The alternative
<metric-pce> ::= <PCE-ID> <metric-argument-list> <metric-argument-list> ::= <metric-argument> [<metric-argument-list>] <metric-argument> ::= <PROC-TIME> | <OVERLOAD>
or equivalently
<metric-pce> ::= <PCE-ID> (<metric-argument>...) <metric-argument> ::= <PROC-TIME> | <OVERLOAD>
does not reflect that each metric-argument should appear at most once. This can be addressed verbosely:
<metric-pce> ::= <PCE-ID>
( <PROC-TIME> | <OVERLOAD> | <PROC-TIME><OVERLOAD> )
<metric-pce> ::= <PCE-ID>
( <PROC-TIME>[<OVERLOAD>] | [<PROC-TIME>]<OVERLOAD> )
Here the semantic is that we require any object of the set {PROC-TIME, OVERLOAD} to be present, and there should be at least one. Note that currently there are only a few cases where the "non-empty set" case arises.
This document does not modify the content of defined PCEP objects and TLVs.
This document is not normative, the normative definition is included in the existing specs. This does not preclude integration with a future revision of such documents.
This draft does not provide any new extensions to PCEP, but it includes requirements specified by existing RFCs for illustrative purpose.
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].
This section provides the proposed RBNF notation for the PCEP messages. Specific constructs or grammar rules that appear in several messages or deserve special considerations are described first.
<of-list> ::= <OF> [<of-list>]
<metric-list> ::= <METRIC> [<metric-list>]
<vendor-info-list> ::= <VENDOR-INFORMATION> [<vendor-info-list>]
<pce-id-list> ::= <PCE-ID> [<pce-id-list>]
-- (note: named pce-list in original)
<svec-tuple> ::= <SVEC>
[<OF>]
[<metric-list>]
[<vendor-info-list>]
[<GC>]
[<XRO>]
<svec-tuple-list> ::= <svec-tuple> [<svec-tuple-list>]
Note that, again, as an example [RFC7150] defines:
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<metric-list>]
[<vendor-info-list>]
[<svec-list>]
There are two problems, ordering and naming. So, we use the afore defined svec-tuple-list. The construct is updated to reflect the new name and to have the same relative order in the attributes that constrain a individual request
A metric-pce-id is a rule that associates a PCE identified by its PCE-ID to a list of metric arguments.
<metric-pce-id> ::= <PCE-ID>
(<PROC-TIME> [<OVERLOAD>] |
[<PROC-TIME>] <OVERLOAD> )
<metric-pce-id-list> ::= <metric-pce-id> [<metric-pce-id-list>]
See [RFC5886] for the definition of specific/general and in-band/out-of-band.
<monitoring> ::= <MONITORING> <PCC-ID-REQ>
<monitoring-request> ::= <monitoring> [<pce-id-list>]
<monitoring-response> ::= <monitoring>
(<specific-monitoring-metrics-list> |
<general-monitoring-metrics-list>)
<specific-monitoring-metrics-list> ::=
<specific-monitoring-metrics>
[<specific-monitoring-metrics-list>]
<general-monitoring-metrics-list> ::=
<general-monitoring-metrics>
[<general-monitoring-metrics-list>]
<specific-monitoring-metrics> ::=
<RP> <monitoring-metrics>
<general-monitoring-metrics> ::=
<monitoring-metrics>
<monitoring-metrics> ::=
<metric-pce-id-list>
Attributes are used to constrain a request, or to qualify a path (defined later in this document). However, it is not straightforward to define an attributes construct, since it may change for P2P or P2MP paths, and some objects (e.g. BANDWIDTH) may appear multiple times, with different semantics:
-- Note: it is expected that each attribute may appear
-- just once, even if the RBNF grammar allows it. If an
-- object is allowed to repeat a list is used (e.g.
-- metric-list
-- Note: the ordering is implied by the notation below.
-- For P2P reoptimizations
<rro-bw-pair> ::= <RRO> [<BANDWIDTH>]
-- For P2MP reoptimizations
<rro-list-bw> ::= <rro-list>[<BANDWIDTH>]
-- Some attributes only apply to P2MP computations
<attribute> ::=
<CLASSTYPE> |
<LSPA> |
<OF> |
<BANDWIDTH> |
<metric-list> |
<vendor-info-list> |
<IRO> |
<BNC> | -- Only in P2MP
<XRO> |
<RRO> | -- Used in Reports
<rro-bw-pair> | -- Only in P2P
<rro-list-bw> | -- Only in P2MP
<LOAD-BALANCING> |
<INTER-LAYER> |
<SWITCH-LAYER> |
<REQ-ADAP-CAP>
<attributes> ::= <attribute> [<attributes>]
A path is defined consistently as a qualified ERO (or ERO/SERO for P2MP). Similar path constructs appear, notably, in PCEP responses, in solicited/unsolicited state reports and in update requests. The following remarks apply:
The <path> construct is then defined as:
<ero-sero-list> ::= (<ERO> | <SERO>) [<ero-sero-list>]
<path> ::= <ERO> [<attributes>]
<p2mp-path> ::= <ero-sero-list> [<attributes>]
<path-list> ::= <path>|<p2mp-path> [<path-list>]
<Open Message> ::= <Common Header>
<OPEN>
<KeepAlive Message>::= <Common Header>
Note that the actual parsing depends on the content (flags) of the Request Parameters (RP) object, notably expansion and P2MP. In some cases, this may be considered redundant, e.g. the presence of a PATH_KEY object and the corresponding flag.
(<a with x=v> <b>) | (<a with x!=v> <c>)
[Editor's note: from a notation perspective, we lack a way to express "if object a field x has value v then include object b, else include object c". RNBF extensions can be considered in future revisions of the PCEP protocol, e.g. defining new constructs :
The PCReq message contains a possibly monitored list of requests, some of which may be grouped by SVEC tuples.
<PCReq Message>::= <Common Header>
[<monitoring-request>]
[<svec-tuple-list>]
<request-list>
where:
<request-list> ::= <request> [<request-list>]
-- A request is either an expansion, a P2P request or a P2MP request
<request> ::= <expansion> |
<p2p_computation> |
<p2mp_computation>
<expansion> ::= <RP><PATH-KEY>
<p2p_computation> ::= <RP><ENDPOINTS>
[<LSP>]
[<attributes>]
<p2mp_computation> ::= <RP><tree-list>
[<attributes>]
-- For a P2P computation
-- in RFC6006 there is a bw per tree,
-- it is intended to be an optimization for an RRO list
<tree> ::= <ENDPOINTS>(<rro-bw-pair>|<rro-list-bw>)
<tree-list> ::= <tree> [<tree-list>]
<tree> ::= <ENDPOINTS> <rro-bw-pair>
<PCRep Message> ::= <Common Header>
[<svec-tuple-list>]
<response-list>
-- Note: should clarify the use of SVEC tuple list
where
<response-list> ::= <response> [<response-list>]
-- An individual response may include monitoring info
<response> ::= <RP> [<monitoring>] [<LSP>]
(<success> | <failure>) [<monitoring-metrics>]
-- Note: should clarify P2MP attributes. P2MP response
-- also includes endpoint-path-pair-list. TBD
<success> ::= <path-list>
<failure> ::= <NO-PATH> [<attributes>]
<PCMonReq Message> ::= <Common Header>
<monitoring-request>
[[<svec-tuple-list>] <request-list>]
<PCMonRep Message> ::= <Common Header>
<monitoring-response>
<PCNtf Message> ::= <Common Header> ( <solicited-notify> | <unsolicited-notify> ) where <solicited-notify> ::= <request-id-list> <notification-list> <unsolicited-notify> ::= <notification-list> <request-id-list> ::= <RP> [<request-id-list>] <notification-list> ::= <NOTIFICATION> [<notification-list>]
<PCErr Message> ::=
<Common Header>
( <solicited-error> | <unsolicited-error> )
where
-- Solicited error is bound to a Request Paramters (RP) list or
-- to a Stateful Request Parameters (SRP) list
<solicited-error> ::= <request-id-list> | <stateful-request-id-list>
-- Unsolicited Error can be due to handshake or asynchronous
<unsolicited-error> ::= <handshake-error> | <pcep-error-list>
-- Handshake Error is bound to an OPEN object
<handshake-error> ::= <pcep-error-list> <OPEN>
<request-id-list> ::= <RP> [<request-id-list>]
<stateful-request-id-list> ::= <SRP>[<stateful-request-id-list>]
<pcep-error-list> ::= <PCEP-ERROR> [<pcep-error-list>]
The PCRpt format is defined in [I-D.ietf-pce-stateful-pce]. Note, however, that the end-of-sync, solicited-report and unsolicited-report are introduced for convenience, and that the RRO object is already part of the attributes construct.
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report> [<state-report-list>]
<state-report> ::=
<end-of-sync> |
<solicited-report> |
<unsolicited-report>
-- LSP flags signal end of synchronization
<end-of-sync> ::= <LSP>
<solicited-report> ::= <SRP> <LSP> <path>
<unsolicited-report> ::= <LSP> <path>
As [I-D.ietf-pce-stateful-pce].
<PCUpd Message> ::= <Common Header>
<udpate-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
As [I-D.ietf-pce-pce-initiated-lsp]. Note that the <path> construct is used here.
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-request-list>
Where:
<PCE-initiated-lsp-request-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-request-list>]
-- A request can be an instantiation or a deletion. SRP / LSP
-- flags are used to select
<PCE-initiated-lsp-request> ::=
<PCE-initiated-lsp-instantiation> |
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
<ENDPOINTS>
<path>
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
This document does not define additional management considerations.
This document does not define additional security considerations.
This work was supported in part by the PACE Support Action (http://ict-pace.net/) project under grant agreement number 619712.