Presentation is loading. Please wait.

Presentation is loading. Please wait.

PCEP extensions for GMPLS draft-margaria-pce-gmpls-pcep-extensions-01 Cyril Margaria Nokia Siemens Networks Oscar González de Dios Telefonica Investigacion.

Similar presentations


Presentation on theme: "PCEP extensions for GMPLS draft-margaria-pce-gmpls-pcep-extensions-01 Cyril Margaria Nokia Siemens Networks Oscar González de Dios Telefonica Investigacion."— Presentation transcript:

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 : ::= [ ] [ [ ]...] ::= | | ::= [ ] ::= (( )| | )[ ]

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


Download ppt "PCEP extensions for GMPLS draft-margaria-pce-gmpls-pcep-extensions-01 Cyril Margaria Nokia Siemens Networks Oscar González de Dios Telefonica Investigacion."

Similar presentations


Ads by Google