PCEP extensions for GMPLS draftmargariapcegmplspcepextensions01 Cyril Margaria Nokia

  • Slides: 9
Download presentation
PCEP extensions for GMPLS draft-margaria-pce-gmpls-pcep-extensions-01 Cyril Margaria Nokia Siemens Networks Oscar González de Dios

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

Document Motivation/background Current PCEP protocol does not cover the complete feature set of GMPLS

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 IPv 4/IPv 6 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-pcep-extensionsfor-gmpls-00. txt into the document • Extend support

Differences from last version • Merge draft-zhang-pcep-extensionsfor-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-pcepextensions-for-gmpls-00. txt Clarified the requirements and needed extensions between all authors

Merge of draft-zhang-pcepextensions-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

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>: : =<IPV 4_ADDRESS>|<IPV 6_ADDRESS>|<UNNUMBER ED_ENDPOINT> <endpoint-restrictions> : : = <LABEL_REQUEST><labelrestriction>[<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

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

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

Next Steps • the authors solicit the WG experts to review the document and

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 RFC 5440 does not

GENERALIZED BW as TLV • Problem : strict interpretation of RFC 5440 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