Subject: RE: [NSIS] NTLP draft

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

Hi Robert, 

see comments inline

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Monday, November 17, 2003 4:07 PM
> To: Attila Báder (IJ/ETH); [email-masked]
> Cc: Lars Westberg (KI/EAB); [email-masked]; 'Henning
> Schulzrinne'
> Subject: RE: [NSIS] NTLP draft
> 
> 
> 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.
> 
Yes, exactly, 

> 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).

Yes, we propose it instead of multi-level encapsulation and I think this is an important feature for achieving scalability.

> 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.)

I think we should distinguish different kind of aggregations e.g. per routing states or per DSCP. In the first case, I think, it would be reasonable if NTLP could bind these sessions in the (de)aggregator nodes. In the second case DSCP and level indicator could be used to bind messages together. It may be enough if NSLP layer knows about this relationship but may be I am wrong.

Best regards, Attila

> 
> 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
> > 
> 
> --
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
> 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Nov 2003 09:44:54 +0100

Hi Attila

Yes, indeed this type of solution can be used instead of the multi-level
encapsulation.

Best Regards,
Georgios

----- Original Message -----
From: "Attila Báder (IJ/ETH)" <[email-masked]>
To: "Hancock, Robert" <[email-masked]>; <[email-masked]>
Cc: "Lars Westberg (KI/EAB)" <[email-masked]>;
<[email-masked]>; "'Henning Schulzrinne'" <[email-masked]>
Sent: Tuesday, November 18, 2003 5:42 PM
Subject: RE: [NSIS] NTLP draft

> Yes, we propose it instead of multi-level encapsulation and I think this
is an important feature for achieving scalability.
> I think we should distinguish different kind of aggregations e.g. per
routing states or per DSCP. In the first case, I think, it would be
reasonable if NTLP could bind these sessions in the (de)aggregator nodes. In
the second case DSCP and level indicator could be used to bind messages
together. It may be enough if NSLP layer knows about this relationship but
may be I am wrong.