The Experts below are selected from a list of 186588 Experts worldwide ranked by ideXlab platform
Young Lee - One of the best experts on this subject based on the ideXlab platform.
-
the path computation element Communication Protocol pcep extension for wavelength switched optical network wson routing and wavelength assignment rwa
RFC, 2020Co-Authors: Young Lee, Ramon CasellasAbstract:This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Path provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.
-
path computation element Communication Protocol pcep requirements for wavelength switched optical network wson routing and wavelength assignment
Tuesday February 3 2015, 2015Co-Authors: Young Lee, G M Bernstein, Jonas Martensson, T Takeda, Takehiro Tsuritani, Gonzalez O De DiosAbstract:This memo provides application-specific requirements for the Path Computation Element Communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document.
-
encoding of objective functions in the path computation element Communication Protocol pcep
RFC, 2009Co-Authors: Young LeeAbstract:The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks, is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g. minimum cost path, widest path, etc.). In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions, therefore it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE. This document defines extensions to the PCE Communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and so that a PCE can report in a path computation reply the objective function that was used for path computation.
Dhruv Dhody - One of the best experts on this subject based on the ideXlab platform.
-
experimental codepoint allocation for the path computation element Communication Protocol pcep
RFC, 2018Co-Authors: Dhruv Dhody, Daniel L King, Adrian FarrelAbstract:IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub- registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review. This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.
-
experimental codepoint allocation for path computation element Communication Protocol pcep
2017Co-Authors: Daniel L King, Dhruv DhodyAbstract:IANA assigns values to the Path Computation Element (PCE) Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a new top-level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Consensus. This document seeks to mark some codepoints for experimental usage of PCEP.
-
update to the include route object iro specification in the path computation element Communication Protocol pcep
RFC, 2016Co-Authors: Dhruv DhodyAbstract:The Path Computation Element Communication Protocol (PCEP) enables Communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit. This document updates RFC 5440 regarding the IRO specification.
-
informal survey into include route object iro implementations in path computation element Communication Protocol pcep
2014Co-Authors: Dhruv DhodyAbstract:During discussions of a document to provide a standard representation and encoding of Domain-Sequence within the Path Computation Element (PCE) Communication Protocol (PCEP) for Communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. It was determined that there was a need for clarification with respect to the ordered nature of the Include Route Object (IRO). Since there was a proposal to have a new IRO type with ordering, as well as handling of Loose bit (L-Bit), it felt necessary to conduct a survey of the existing and planned implementations. This document summarizes the survey questions and captures the results. Some conclusions are also presented. This survey was informal and conducted via email. Responses were collected and anonymized by the PCE working group chairs.
Tarek F. Abdelzaher - One of the best experts on this subject based on the ideXlab platform.
-
A spatiotemporal Communication Protocol for wireless sensor networks
IEEE Transactions on Parallel and Distributed Systems, 2005Co-Authors: Tian He, John A. Stankovic, Chenyang Lu, Tarek F. AbdelzaherAbstract:In this paper, we present a spatiotemporal Communication Protocol for sensor networks, called SPEED. SPEED is \nspecifically tailored to be a localized algorithm with minimal control overhead. End-to-end soft real-time Communication is achieved by \nmaintaining a desired delivery speed across the sensor network through a novel combination of feedback control and nondeterministic \ngeographic forwarding. SPEED is a highly efficient and scalable Protocol for sensor networks where the resources of each node are \nscarce. Theoretical analysis, simulation experiments, and a real implementation on Berkeley motes are provided to validate the claims.
Adrian Farrel - One of the best experts on this subject based on the ideXlab platform.
-
experimental codepoint allocation for the path computation element Communication Protocol pcep
RFC, 2018Co-Authors: Dhruv Dhody, Daniel L King, Adrian FarrelAbstract:IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub- registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review. This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.
-
extensions to the path computation element Communication Protocol pcep for inter layer mpls and gmpls traffic engineering
RFC, 2017Co-Authors: Tomonori Takeda, Fatai Zhang, Eiji Oki, Adrian FarrelAbstract:The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE Communication Protocol (PCEP) is designed as a Communication Protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.
-
extensions to the path computation element Communication Protocol pcep for route exclusions
RFC, 2009Co-Authors: Tomonori Takeda, Eiji Oki, Adrian FarrelAbstract:The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions". The PCE Communication Protocol (PCEP) is designed as a Communication Protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]
Alvin Lim - One of the best experts on this subject based on the ideXlab platform.
-
rtdd a real time Communication Protocol for directed diffusion
Wireless Communications and Networking Conference, 2008Co-Authors: Kenan Casey, R Neelisetti, Alvin LimAbstract:In this paper, we propose Real-Time Directed Diffusion (RTDD), a real-time Communication Protocol for directed diffusion. Using the mechanisms provided by directed diffusion, we implement a prioritized scheduling policy over diffusion. With just a few extensions, RTDD significantly enhances the directed diffusion Protocol, allowing time-critical flows to delivery more packets on time. We also propose two new scheduling policies which do not require location knowledge. We simulate RTDD in ns-2 and compare its performance to standard directed diffusion. Results show that RTDD delivers significantly more packets on time than directed diffusion alone.
