Subject: RE: [NSIS] NTLP draft

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 17 Nov 2003 15:06:40 -0000

hi attila,

thanks for this input. if i understand correctly, what you
are saying is that you would like nodes to be able to run
more than one signalling session for a given flow; one of
those sessions would have the property that it might not
need all the NTLP functions to be invoked.

this is a possible approach. there are clearly simplifications
compared to other approaches (which are equivalent to using
a single message carrying the data for >1 session, which 
obviously implies some multi-level aspects to the encapsulation
used).

OTOH what needs to be understood here is how much the different 
sessions need to 'know' about each other, and which layer in the 
NSIS stack knows about this relationship. in particular, if one session
needs 'help' from the other to function correctly (e.g. 
congestion management or error reporting), the edge nodes need
to understand the binding at the GIMPS level; at the moment, it
isn't clear to me whether this specific support in the protocol.
(it's similar to the tunnel binding question, see section 6.5
of the draft.)

r.

> -----Original Message-----
> From: Attila Báder (IJ/ETH) [mailto:[email-masked]]
> Sent: Friday, November 14, 2003 08:51
> To: 'Henning Schulzrinne'; Hancock, Robert; [email-masked]
> Cc: Lars Westberg (KI/EAB); [email-masked]
> Subject: RE: [NSIS] NTLP draft
> 
> 
> 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