Subject: RE: [NSIS] NTLP draft

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Fri, 14 Nov 2003 15:51:18 +0100

Hi Robert and Henning,

We had a discussion with Lasse and Georgios about the NTLP draft and we are sending some comments regarding NTLP draft.

We think NSLP an NTLP should support at least the same scenarios as RSVP (except multicast). 
One example is the scenario supported by the RSVP aggregation protocol(RFC3175).
In this scenario the following node types are supported:
* aggregating router: the first router that enters an aggregated region;
* deaggregating router: the last router in the aggregation region
* interior router: any router in the aggregating region that is neither 
an aggregating router nor deaggregating router.

What is important to note is:
* the end to end RSVP messages are hidden from the interior routers inside the aggregation region. In other words, for the end to end Resv messages, the Deaggregating router is the next signaling peer of the Aggregating router.
* Different messages (e.g., Aggregated Path and Aggregated Resv) are used (locally) between Aggregating router and Deaggregating to provide aggregated reservations.
* an aggregation scheme is able to accomodate recursive aggregation, with aggregate reservations being themselves aggregated. The aggregation level is written in the 2 byte field of the router alert option. It can therefore, be considered that for each level of aggregation different aggregating/deaggregating signaling peers are needed. 

Therefore, we propose two requirements for the NTLP:

* Support of multiple levels of signaling transport associations between NTLP peers. For example, in the scenario used for RSVP aggregation, many NTLP signaling associations could be applied in the aggregated region. One signaling transport association is used for the end to end type of reservations. For each aggregation level a different signaling transport association is required.

*  Allow the support of NTLP minimal processing or bypass nodes for some signaling transport associations.
For example, in the scenario used for RSVP aggregation, when the signaling transport association is used for the end to end type of reservations, the NTLP at the interior routers in the aggregated region should carry out minimal processing. This is due to the fact that only the aggregating and deaggregating routers are processing the complete NTLP functionality.

Proposed solution:
One solution to these requirements could be to specify different router-alert "value" to differentiate between signaling associations. A pre-configured policy could be set in the routers to identify the appropriate signalling association.

Best regards, Lasse, Georgios, Attila

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis