60 likes | 188 Views
An QoS ALSP (ULSP) proposal. Georgios.Karagiannis@eln.ericsson.se. Why this presentation?. Present a concept that includes additions to the concept introduced in draft-braden-2level-signal-arch-01.txt Elicit feedback from the WG!. Concept:.
E N D
An QoS ALSP (ULSP) proposal • Georgios.Karagiannis@eln.ericsson.se
Why this presentation? • Present a concept that includes additions to the concept introduced in draft-braden-2level-signal-arch-01.txt • Elicit feedback from the WG!
Concept: Separation in two main protocol levels, transport (CSTP) and application (ALSP or ULSP) • Application level: • similar to the ALSP used in draft-braden-2level-signal-arch-01.txt • differences: • an ALSP that can enhance scalability and can maintain the following state management types: • per flow request =>per flow state in ALSP and CSTP; • per aggregated request=>per-aggregate state in ALSP and CSTP; • per-flow or aggregate request=> One state per traffic class in ALSP and no need for state in CSTP. A traffic class state is a state associated to an independent number of flows that are belonging to the same traffic class;
Concept: Separation in two main protocol levels, transport (CSTP) and application (ALSP or ULSP) • Transport level: • similar to the CSTP used in draft-braden-2level-signal-arch-01.txt • differences (due to the requirement that CSTP has to be suitable to the proposed ALSP): • extension of CSTP to have stateless operation in a node: • CSTP stateless node: CSTP aware node that does not maintain a CSTP state but is maintaining an ALSP state per traffic class; • the detection of lost signaling messages on CSTP stateless nodes is provided by the reliable delivery procedure available on CSTP statefull nodes
Discussion • Is the presented concept acceptable to the WG?