Subject: [NSIS] LIH (was: ntlp drafts differences)

From: Kappler Cornelia <[email-masked]>
Date: Tue, 29 Jul 2003 23:30:30 +0200

Hi Nary, see inline

> > - Whether a NE know its next hop peer.
> > In Melindas NTLP, the NE just knows its previous peer. The next NE
> peer is discovered by a PATH-like message and subsequently addressed
> implicitly.
> > In Hennings NTPL, the NE may request to be informed of the next NE
> peer's address.
> > To my knowledge, knowing the address of the next NE peer is
> necessary for channel security which we require to at least be
> possible (Requirements ID 5.7.5). So to me this looks like a necessary
> feature.
> >
> > And that's it...!?
> 
> It is possible that a NE does not know the next node to send a
> message. By examining the RSVP-HOP (previous hop) object and INTEGRITY
> object, a NE can know which NE has sent this message and which key is
> used (following the security association between them). Maybe I don't
> understand clearly what you mean " next NE peer is necessary for
> channel security ".

As Hannes already pointed out, in order to establish a security association / utilize the correct one you need to know the next NE peer.

> 
> > - do we need a Logical Interface Handle?
> 
> LIH is used for multicast session. According to me, it is not used if
> we don't mind multicast signaling applications.

I think we should be careful to understand what LIH is really necessary for. It is true (according to my understanding from reading 2205) that LIH is necessary to correctly route multicast RESV messages through tunnels over non-multicast aware routers. But is this the only usage?

For example there is a - for me somewhat cryptic - paragraph in 2205 saying "The LIH may also be useful when RSVP reservations are made over a complex link layer, to map between IP layer and link layer flow entities."  

In fact, more generally, 2205 says the LIH is used to identify the (logical) interface on which the PATH message was sent out and on which the reservation is to be established. The RESERVE may arrive at a different interface, e.g. after traversing a non-RSVP cloud, or because of a tunneling situation, and the router must be enabled to asign the RESERVE to previously established PATH state.

Do we need the this feature? Remember, although we may not have PATH/RESV, we do need reverse routing state for some nslps. Below an attempt at a more detailed analysis (it would be nice if an RSVP expert could shed more light on this) - excuse the length:

Why would the router have difficulties assigning the RESERVE to PATH state on a different (logical) interface?

Is it because processing is done per interface, and these processes dont talk to each other? Not in our situation, since we have the concept of an NE per node, and not NE per interface.

Or is it because the session identifier in the RESV is not sufficient to uniquely identify the corresponding PATH state? I think such a situation can happen, but only in the special case of tunnels through a non-multicast node - not for other tunnels or general non-RSVP clouds: 

Assume a mc session originates in a host attached to router A. The next hop router B is non-mc. However the mc session branches in B towards routers C and D. In such a situation A would establish one tunnel each towards C and D. These tunnels would all leave A towards B via the same interface. The original PATH message is replicated, such that there is one traveling in each tunnel, popping out at C and D respectively. (Note we dont care about the reservation for the tunnels. This is only covered in 2746. We are just interested in correctly routing the RSVP messages) When C and D send back the RESVs, which they address directly to A, A needs some means to attach the RESVs to the correct tunnels. Obviously the session ID is identical. Here the LIH, which is different for each tunnel, comes to rescue.

So, as we dont cover mc for now, we dont need to cover this situation either. Therefore, I come to the same conclusion after all ;-) we dont need the LIH. It might very well be though that I missed something.

Cornelia

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Thu, 31 Jul 2003 12:21:10 +0200

hi Cornelia,

When I wrote that a NE can send a downstream signaling message without
knowing its next NE, I thought about a security association (SA) in domaine.
That means every NE has a SA, which is known in a domaine. So it does not
need to know its next NE. Sorry, I got a mistake.

LIH, in fact, I think we can use SESSION_ID (of NSIS) for LIH. So LIH is not
necessary anymore. Of course, SESSION_ID can be used for a multicast
signaling application session. But SESSION_ID structure is still an open
issue and multicast is out of scope of NSIS.

Nary Tra,
ENST, Paris.

----- Original Message -----
From: Kappler Cornelia <[email-masked]>
To: 'Thanh Tra LUU' <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 29, 2003 11:30 PM
Subject: [NSIS] LIH (was: ntlp drafts differences)

> As Hannes already pointed out, in order to establish a security
association / utilize the correct one you need to know the next NE peer.
> I think we should be careful to understand what LIH is really necessary
for. It is true (according to my understanding from reading 2205) that LIH
is necessary to correctly route multicast RESV messages through tunnels over
non-multicast aware routers. But is this the only usage?
>
> For example there is a - for me somewhat cryptic - paragraph in 2205
saying "The LIH may also be useful when RSVP reservations are made over a
complex link layer, to map between IP layer and link layer flow entities."
>
> In fact, more generally, 2205 says the LIH is used to identify the
(logical) interface on which the PATH message was sent out and on which the
reservation is to be established. The RESERVE may arrive at a different
interface, e.g. after traversing a non-RSVP cloud, or because of a tunneling
situation, and the router must be enabled to asign the RESERVE to previously
established PATH state.
>
> Do we need the this feature? Remember, although we may not have PATH/RESV,
we do need reverse routing state for some nslps. Below an attempt at a more
detailed analysis (it would be nice if an RSVP expert could shed more light
on this) - excuse the length:
> Is it because processing is done per interface, and these processes dont
talk to each other? Not in our situation, since we have the concept of an NE
per node, and not NE per interface.
>
> Or is it because the session identifier in the RESV is not sufficient to
uniquely identify the corresponding PATH state? I think such a situation can
happen, but only in the special case of tunnels through a non-multicast
node - not for other tunnels or general non-RSVP clouds:
>
> Assume a mc session originates in a host attached to router A. The next
hop router B is non-mc. However the mc session branches in B towards routers
C and D. In such a situation A would establish one tunnel each towards C and
D. These tunnels would all leave A towards B via the same interface. The
original PATH message is replicated, such that there is one traveling in
each tunnel, popping out at C and D respectively. (Note we dont care about
the reservation for the tunnels. This is only covered in 2746. We are just
interested in correctly routing the RSVP messages) When C and D send back
the RESVs, which they address directly to A, A needs some means to attach
the RESVs to the correct tunnels. Obviously the session ID is identical.
Here the LIH, which is different for each tunnel, comes to rescue.
>
> So, as we dont cover mc for now, we dont need to cover this situation
either. Therefore, I come to the same conclusion after all ;-) we dont need
the LIH. It might very well be though that I missed something.