PCEP extensions for GMPLS

draft-margaria-pce-gmpls-pcep-extensions-01

Cyril MargariaNokia Siemens Networks

Oscar González de DiosTelefonica Investigacion y Desarrollo

Fatai ZhangHuawei Technologies

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)

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

Merge of draft-zhang-pce-pcep-extensions-for-gmpls-00.txt

Clarified the requirements and needed extensions between all authors

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>]

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

NO_PATH extensions

Two flags are newly defined:-PM (Protection Mismatch) flag : Specifies the mismatch of theprotection type in the request-NR (No Resource) flag: Specifies that the resources are notsufficient to provide the path.

- aligned with existing documents

Next Steps

• the authors solicit the WG experts to review the document and comment.

• Consider Generalized Bandwidth as TLV

• Consider WG adoption

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