Download presentation
Presentation is loading. Please wait.
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.