Subject: RE: [NSIS] RE: Crossover node discovery issue

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 1 Sep 2003 11:04:29 +0100

hi jukka,

i think i agree that an important attribute of the
crossover node is that it is a node storing some
signalling application state (not just any signalling-
aware node). this is another reason why dealing with
crossover node issues (generally, mobility issues)
would have to be handled in NSLPs rather than 
in the NTLP (at least, that's what I think).

this leaves open some interesting questions about
how to deal with the nsis equivalent of 'local repair'.
suppose a node is monitoring routing state to detect
route-change events in order to react to them more
quickly than waiting on periodic refreshes. if that 
node isn't itself managing the signalling application
state, should it attempt to tell the nodes which are
that something has changed?

r.

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: Monday, September 01, 2003 05:53
> To: [email-masked]
> Cc: Hancock, Robert
> Subject: Re: [NSIS] RE: Crossover node discovery issue
> 
> 
> 
> (retry 1, first post was rejected...?)
> 
> Hi,
> 
> about the definition of x-over router, following an RSVP-style of 
> definition, the cross-over router would be defined (only?) mainly for 
> situations where a new session id/state is being established. 
> At least for 
> RSVP, the cross-over router is only meaningful when a router 
> receives a 
> Path message and notices that an existing PSB (almost) matches the 
> incoming message, but in incoming interface differs. Thus, 
> for NSIS, this 
> would be something along "the NSLP aware node which, for a 
> given incoming 
> new session establishment (or session change request) from interface 
> newIF, already has the session information stored on one or 
> more different 
> incoming interfaces. In other words, the newly arrived 
> message identifies 
> a new incoming interface for an existing session." (change 
> "interface" 
> for "NE", if you like).
> 
> Regards,
> Jukka
> 

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

---

From: "Charles Q. Shen" <[email-masked]>
Date: Tue, 2 Sep 2003 17:35:33 -0400

Hi Robert and Jukka,

That's indeed a very interesting problem as a result of the layer split.
I tend to look at it as mainly containing two separate but closely
related cases, 

    I ) Routing change (caused by various reasons, load balancing, node
failure ..., usually inside the network ) 
    II) Host address change (typically caused by mobililty, usually at
network edge)

It looks pretty reasonable to me that the first case should be taken
care of by NTLP first. However, this low level change could also affect
specific NSLPs. There are at least two possibilies then, a) give NTLP
knowledge about whether there is related NSLP in the same node, so it
can deliver the route change signal as appropriate. b) otherwise, with
no knowlege of specific NSLP at the node, NTLP may optionally signal to
the upper layer (as a fast recovery enhancement).  

In the second case, I feel it is preferable to have the NSLP handle it.
NTLP may or may not be directly involved. One question here is probably
how the Mobility machanism exactly interacts with NSIS, through NTLP or
NSLP or both?

There could be cases that sits somewhere in between the above two cases
that need further consideration, e.g., in FMIP or HMIP.

Finally, I agree upon the high level view of the Cross-over router you
mentioned. A detailed look may need to differentiate upstream/downstream
Cross-over routers and the way they are identified etc

Best regards,

Charles 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hancock, Robert
> Sent: Monday, September 01, 2003 6:04 AM
> To: 'Jukka MJ Manner'; [email-masked]
> Subject: RE: [NSIS] RE: Crossover node discovery issue
> 
> 
> hi jukka,
> 
> route-change events in order to react to them more quickly 
> than waiting on periodic refreshes. if that

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 05 Sep 2003 14:26:33 +0200

Hi Charles, Robert, Jukka & all,

> failure ..., usually inside the network ) 

Mobility can also cause route change, e.g., in home agent, or other 
localized mobility agents.

> how the Mobility machanism exactly interacts with NSIS, through NTLP or

Good question. Probably it is necessary to know the changed address for 
NTLP. It would be helpful in some cases, e.g., to let the trigger of a 
local repair find out the actual route which the signaling message will 
follow. About local repair trigger - roughly there are several possible 
means (will be explained in detail in an upcoming short I-D):

a) through end-to-end soft state refresh (for both downstream & 
upstream: slow)
b) through refresh & x-router discovery due to a mobility-caused route 
change in CN or mobility agents (for downstream: fast) and MN (for 
upstream: fast)
c) through refresh due to a mobility-caused route change/address change 
in MN & MN-initiated discovery of x-router (for both downstream & 
upstream: fast but more complex).

My preference is b). As you also mentioned above, NTLP is involved in 
mobility anyway, it might make sense to have NSLP interfacing with NTLP 
for mobility info other than directly with mobility route change 
whatsoever; this can also be advantageous for clearing the 2-layer arch.
> that need further consideration, e.g., in FMIP or HMIP.

These localized mobility cases can re-apply the same scheme to MIP.

Cheers,
Xiaoming
>>>definition, the cross-over router would be defined (only?) 
>>
>>mainly for 
>>
>>>new session establishment (or session change request) from 
>>
>>interface 
>>