1. PCEP extensions for GMPLS
draft-margaria-pce-gmpls-pcep-extensions-01
Cyril Margaria
Nokia Siemens Networks
Oscar González de Dios
Telefonica Investigacion y Desarrollo
Fatai Zhang
Huawei Technologies

2. Document Motivation/background
Current PCEP protocol does not cover the complete feature set of GMPLS networks, especially:
Traffic specification in GMPLS is richer (matching the different data planes) allowing finer control (e.g. mean rate / peak rate, VC)…
PCEP currently supports 32 bit float bandwidth
Resources control : GMPLS path computation may require label constraints (e.g. WCC in WSON)
PCEP has some basic support (e.g. vendor constraints) and IRO/XRO
Clarify semantics
Different addressing for endpoints (unnumbered interfaces are not currently supported in PCEP).
PCEP currently supports IPv4/IPv6 endpoints (Node Ids / numbered ifaces)
Protection requirements
The goal of the document is extend PCEP in a non-layer specific way, aligned with RSVP-TE encoding and with other PCE WG documents and drafts (for instance inter-layer)

3. Differences from last version
Merge draft-zhang-pce-pcep-extensions-for-gmpls-00.txt into the document
Extend support for ENDPOINTS
Allow a mix of endpoint types (new C-Type)
Clarify endpoint label TLVs and Encoding
Add error code considerations
Include comments

4. Merge of draft-zhang-pce-pcep-extensions-for-gmpls-00.txt
Clarified the requirements and needed extensions between all authors

5. ENDPOINTS Ingress/egress endpoint types do not need to be consistent
 TLV per ingress/egress
A set of restrictions (set of TLV) is part of the endpoint :
<generalized-endpoint-tlvs>::=
<endpoint>[<endpoint-restrictions>]
<endpoint> [<endpoint-restrictions>]
[<endpoint> [<endpoint-restrictions>] ...]
<endpoint>::=<IPV4_ADDRESS>|<IPV6_ADDRESS>|<UNNUMBERED_ENDPOINT>
<endpoint-restrictions> ::= <LABEL_REQUEST><label-restriction>[<endpoint-restrictions>]
<label-restriction> ::= ((<LABEL><UPSTREAM_LABEL>)|<LABEL_SET>|<SUGGESTED_LABEL_SET>)[<label-restriction>]

6. Label Objects
Purpose: to restrict the resources to be considered in the Path Computation
Separate the LABEL_REQUEST and content to be more in-line with RSVP encoding
Support of suggested label(s)
Support of Labelsets

7. NO_PATH extensions
Two flags are newly defined: -PM (Protection Mismatch) flag : Specifies the mismatch of the protection type in the request -NR (No Resource) flag: Specifies that the resources are not sufficient to provide the path.
- aligned with existing documents

8. Next Steps
the authors solicit the WG experts to review the document and comment.
Consider Generalized Bandwidth as TLV
Consider WG adoption

9. GENERALIZED BW as TLV
Problem : strict interpretation of RFC5440 does not allow that
Body has fixed size of 4 Byte, no TLVs
New C-Types : 3 and 4
existing generalized BW
One TLV per BW type
Key requirements:
Allow several BW type to be described (for ML requests)
Allow asymetric BW (upstream)
C-Type 1 and 2 can be used for compatibility