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

From: Kappler Cornelia <[email-masked]>
Date: Wed, 30 Jul 2003 14:33:18 +0200

Stupid question: why do I not just store "outgoing interface ID" in the PATH state rather than LIH? Then I need to do the lookup only once, too.

And then it seems to me the nsis problem in that respect is different to the RSVP problem, and nsis usually doesn't need LIH or similar information: 

The ntlp may be used for all sorts of nslps, not just QoS reservation. ntlp needs to be able to correctly do backwards routing, i.e. assign a message coming in on an arbitrary interface to the correct ntlp state. It can do this using the session ID (plus possibly other flow-specific information - i.e. not LIH or similar); however it does not manage interface specific "reservation state" or whatever other nslp state - which in a general case may not even be bound to a particular interface (or would it be?). Therefore at least ntlp doesn't need "outgoing interface information" (LIH or otherwise).

What about nslp, particulary the QoS nslp? According to the framework (6.1.5), nslp just does signaling for QoS, it doesn't do resource management. The resource management function (RMF) may not even be co-located with the nsis node. So I would conclude, nslp, too, doesn't need to know what interface a reservation will be on.

Welcoming comments on flaws in my analysis, Cornelia.

>   *> One question for clarification:
>   *> 
>   *> How would do you find out the LIH in the first place, 
> without consulting 
>   *> the routing table?
> 
> Presumably you have to do that whenever you send a path 
> message; it saves
> you doing it again when you receive a Resv message. Right?
> 
> Bob
> 
>   *> 
>   *> Bob Braden wrote:
>   *> 
>   *> > I think your analysis is not quite right, but your 
> conclusion seems to
>   *> > be correct.
>   *> > 
>   *> > Assume pure unicast.
>   *> > 
>   *> > When the NSIS equivalent to an upstream RESV message 
> arrives, how does
>   *> > the NSIS program figure out which outgoing interface 
> should have the
>   *> > reservation?  Matching the path state does not help, 
> because path state
>   *> > is bound to incoming interfaces, not outgoing 
> interfaces.  But the NSIS
>   *> > program can make the proper assignment by consulting 
> routing -- what
>   *> > interface will data packets for this session be sent 
> out?  Bind the
>   *> > reservation to that interface.  So, the LIH is not 
> logically necessary.
>   *> > 
>   *> > (OTOH, the LIH is an awfully cheap way to avoid this 
> routing lookup in
>   *> > the NSIS daemon!).
>   *> > 
>   *> > That's the way it seems to me.
>   *> > 
>   *> > Bob Braden
>   *> > 
>   *> > _______________________________________________
>   *> > nsis mailing list
>   *> > [email-masked]
>   *> > https://www1.ietf.org/mailman/listinfo/nsis
>   *> 
>   *> 
>   *> _______________________________________________
>   *> nsis mailing list
>   *> [email-masked]
>   *> https://www1.ietf.org/mailman/listinfo/nsis
>   *> 
> 

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

---

From: Bob Braden <[email-masked]>
Date: Wed, 30 Jul 2003 09:20:17 -0700 (PDT)

*> 
  *> Stupid question: why do I not just store "outgoing interface ID" in the PATH state rather than LIH? Then I need to do the lookup only once, too.
  *> 

Cornelia,

The LIH *is* (an opaque handle on) the "outgoing interface ID.  That
is, it is encoded in a manner that is understood by the sender but not
necessarily by the downstream receiver.

  *> And then it seems to me the nsis problem in that respect is different to the RSVP problem, and nsis usually doesn't need LIH or similar information: 
  *> 
  *> The ntlp may be used for all sorts of nslps, not just QoS reservation. ntlp needs to be able to correctly do backwards routing, i.e. assign a message coming in on an arbitrary interface to the correct ntlp state. It can do this using the session ID (plus possibly other flow-specific information - i.e. not LIH or similar); however it does not manage interface specific "reservation state" or whatever other nslp state - which in a general case may not even be bound to a particular interface (or would it be?). Therefore at least ntlp doesn't need "outgoing interface information" (LIH or otherwise).

It appears that you did not follow what I said.  Indeed, it "doesn't need"
the LIH, as I said, but it may be useful to have it.

  *> 
  *> What about nslp, particulary the QoS nslp? According to the framework (6.1.5), nslp just does signaling for QoS, it doesn't do resource management. The resource management function (RMF) may not even be co-located with the nsis node. So I would conclude, nslp, too, doesn't need to know what interface a reservation will be on.

Your argument seems a little strange, if I understand it.  QoS
reservation is to be one of the applications of NSIS.  For QoS
reservations, you had better know on which outgoing interface to apply
the reservation.  Therefore, either NSLP or NTLP must be able to make
this mapping (In this discussion of LIH, I do not intend to take a
stand on which layer has to provide this functionality; my Two-Level
paper did take a stand on that issue, but you folks are rethinking that
modularity.)

Bob Braden

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 30 Jul 2003 17:50:02 +0100

Bob, Henning, Cornelia,

I think there are two questions being discussed here.

In terms of needing to know the LIH, in the unicast-only case
I think it's clear that the outgoing interface at a node is derivable
from other information associated with signalling messages, namely
some set of header fields (called the "flow-id" in NSIS, more associated
with the SESSION object in RSVP). So, from that point of view, 
knowing the LIH is not needed like it was in RSVP. And, to be honest,
I'd rather do the mapping between header-fields and interface locally
as and when needed rather than relying on indirection via various
handles being passed around, the latter just seems dangerous.

So I don't think the LIH is useful to be sent back to the 
signalling originator. It might still be useful to the receiver - for
example, detecting that it had changed even though the equivalent
of the RSVP_HOP had not changed (i.e. route changes, peer doesn't).
Or, the protocol might detect that some other way. Or, one might
not care about such changes. I think this is a question of detailed
design at this stage.

The other question that has been raised is whether the NTLP can/should
be implementable in a purely 'routing ignorant' way (informally, as
a user space process), or whether it needs closer access to the 
network layer on a node. It would clearly be nice to implement
the NTLP purely in user space, and logically, since the NTLP only
moves messages around and doesn't actually configure interface 
behaviour directly, this could be possible. The NTLP could punt message
routing decisions to the IP stack, and hope that signalling applications
that cared about interfaces found them consistently with the
way the IP stack did (which is then an implementation issue for those
signalling applications).

In practice, I suspect this will be possible in only simple cases.
For example, if you receive messages with scoped addresses, you
need to know which interface they arrive on and control which interface
they are replied to on (this may be simpler if we don't have site-locals
any more, but I'm not certain). Or, if packets are going to be sent
into tunnels which aren't visible to the sending application, 
some layer has to adapt the signalling payloads which refer to header
fields to reflect this. This might mean integration with all sorts of
horrible VPN and other functions (MIP, L2TP, IPsec, ...) but I 
don't see a way round that. Or, if the node is applying some kind of
policy forwarding, the NTLP may need to force a signalling packet out of
the same interface that it knows data packets are going to use, even
if the IP stack would naturally use a different one.

I tend to think of the NTLP as operating system
dependent for this reason. These aspects only have to be done once,
and in a signalling application dependent way. It doesn't necessarily
mean an in-kernel implementation, since modern OSs may allow all sorts
of intimate access to kernel data structures to appropriately privileged
processes.

Cheers,

Robert H.

PS I'd be interested to know if this thinking is different from the 
original CSTP proposal, since I thought it wasn't. (It talks about 
maintaining neighbour state including the local interface used to 
reach the neighbour as well as its IP address, but I assumed this
was just a cached lookup of the local routing table or something
specific for multicast.)

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2003 16:56
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] LIH (was: ntlp drafts differences)
> 
> 
> 
>   *> > 
>   *> > Presumably you have to do that whenever you send a 
> path message; it saves
>   *> > you doing it again when you receive a Resv message. Right?
>   *> 
>   *>  From a practical perspective, if you send a UDP-based 
> PATH message, you 
>   *> wouldn't know which interface it left on. I think even 
> for raw IP 
>   *> packets, the kernel does the routing, without informing 
> the sender of 
>   *> the details of the interface selection decision. (Many 
> of us would like 
>   *> to implement NSIS outside the kernel...)
>   *> 
> 
> Henning,
> 
> Then I don't see how NSIS can work with such a kernel.  See my earlier
> message: NSIS has to be able to ask routing what decisision it will
> make.
> 
> When you say "the kernel", you have to define which kernel you mean.
> Cisco IOS?  Some particular flavor of Unix (different ones do it
> differently).
> 
> This seems to have degenerated into a silly discussion, or 
> else I don't
> get it.
> 
> Bob
>