Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

From: "Gary Kenward" <[email-masked]>
Date: Mon, 8 Jul 2002 13:17:08 -0400

James:

  In a way, yes. But if CT is present, and succeeds, then there
should be no need for MN-AN signalling, thus CT optimizes NSIS completely
away during handover (in this preferred scenario).

  Note that I specifically identified MN-AN NSIS, as I think what happens
within the interior of the AN is a broader discussion. From a seamless
perspective, one would hope that no signalling would be required. However,
this objective may not be possible with some service topologies (e.g. Int
Serv QoS). As I hinted earlier, one could assume the use of CT for internal
router context transfer (e.g. Int Serv configuration/state between IRs), 
unfortunately, there are some serious discover/topological issues that
arise.
NSIS may be the best possible general approach for per flow IR service 
configuration with handovers. On the other hand, some may be willing to live
with topological constraints (PDP context relocation comes to mind here).

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: July 8, 2002 12:39
> To: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH];
> [email-masked]; [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
> 
> 
> Could CT be viewed as an optimization of NSIS signaling?
> 
>             jak
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, July 08, 2002 9:20 AM
> Subject: [Seamoby] RE: [NSIS] Re: 
> draft-westphal-nsis-qos-mobileip-00.txt
> 
> 
> > Hi Gary:
> >
> > Some comments inline:
> >
> > -----Original Message-----
> > From: ext Gary Kenward [mailto:[email-masked]]
> > Sent: 08. July 2002 12:00
> > To: [email-masked]'; 'NSIS'
> > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
> > Sensitivity: Confidential
> >
> >
> > I finally managed to find time to read through Cedric's and 
> Hemant's draft.
> > Overally, I think it is a good description of one possible 
> integrated
> > approach.
> >
> > [Hemant] Please note that the Edge Signaling (MN-AR and 
> AR-AR) and Data Path Signaling (e2e if you will) are not "tightly
> integrated", i.e., they help each other but do not rely on 
> each other (though I admit that the current writeup makes that
> impression). In other words, Data Path Signaling can work (at 
> handoff time) even if Edge Signaling fails.
> >
> > The one general comment I would like to offer up at this 
> time, is that while
> >
> > the draft does a good job of integrating MIP, CT and NSIS 
> concepts, the
> > proposed solutions for QoS negotiation between MN and AN 
> (e.g. the use of
> > the
> > CIN message) is NSIS not CT.
> >
> > [Hemant] Point well taken.
> >
> > CT is concerned with the transfer of forwarding service 
> context between
> > ANRs.
> > NSIS is concerned with the signalling of service 
> requirements. Thus, the
> > issue
> > is not how to interwork the "CT" CIN, for example, with 
> NSIS signalling, but
> > how
> > the CIN, etc., form part of the NSIS solution.
> >
> > [Hemant] I agree. The basic idea is that if CT can help 
> avoid MN-new AR NSIS signaling at handoff time, it is a good 
> proposition.
> Note that context can be constructed at old AR using the 
> information supplied to it by NSIS MN-old AR message at 
> session initiation,
> which can be transported to new AR in CT. If CT fails, one 
> should use MN-new AR NSIS signaling at handoff time, albeit at certain
> loss of seamlessness.
> >
> > [Hemant] Thanks, Hemant
> >
> > This is not simply an issue of adherence to Seamoby/NSIS 
> models or charters.
> > The intention has always been that CT work as a context 
> transfer mechanism
> > with a variety of mobility and service signalling 
> solutions. There is a
> > significant
> > benefit in the real world to be realized in keeping the 
> context transfer
> > solution
> > (CT) independent from the service signalling solution 
> (NSIS) (and the
> > mobility
> > solution - MIP or whatever). I would think that there is 
> also a benefit to
> > keeping
> > the MN to AR service signalling independent of CT.
> >
> > Stated a different way, do we really need two separate 
> solutions for over
> > the air
> > (MN to AN) service signalling?
> >
> > Regards,
> > Gary Kenward
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 10 Jul 2002 17:38:49 -0500

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 5:15 PM
To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Re:

I guess I didn't make my point clear.

The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is
unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed.

Madjid>> don't quite agree. A QoS framework that tightly controls resources, might need to release resources
at old AR and obtain resources at new AR, so CT by itself is not always enough.

I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be
some changes in the QoS specific context definition).

Madjid>> Ok.

Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes
required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others.

            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "Rajeev Koodli" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 10, 2002 11:58 AM
Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt

> James,
>
> As much as I like to see a clean interaction between CT and NSIS,
> I don't see any reason why CT needs to play the role of NSIS optimization,
> not to forget the NSIS didn't even exist back then.
>
> CT is simply a tool you need in your seamless mobility toolbox, it
> eventually
> involved into a container carrying any context you like (even non-IP
> context, as
> long as it is feasible). The profile types, that Rajeev mentioned is aligned
> with
> this line of thinking.
>
> I seriously advise against going back and change CT
> requirements for the sake of optimizing NSIS, which at this point we don't
> know
> what it is. A couple of months from now, we have to revise CT because of a
> security
> related protocol, later for something else.....
>
>
> The later we wait for CT standardization, the more home brewed versions are
> going to pop up, just like Behcet mentioned.
>
> My 1.5 cents (lower dollars)
>
> Madjid
>
> Sent: Monday, July 08, 2002 4:37 PM
> To: Rajeev Koodli; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> > CT is an optimization to avoid signaling and the associated overheads, and
> maintain
> > desirable transport (RTP/TCP)performance. A historical note: CT was not
> designed
> > to be an optimization for NSIS.
> >
>
> Do you mean that the requirements weren't so designed? Because, to my
> knowledge, the WG has not yet settled on a design. We are
> currently awaiting IESG feedback on our requirements. The problem statement
> was just approved by the IESG.
>
>             jak
>
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 11 Jul 2002 10:24:13 +0200

Hi James

> The point I was trying to make is that given CT of QoS 
> context succeeds, NSIS signaling at the new access subnet is
> unnecessary. Thus, it could be viewed as a kind of 
> optimization. If CT fails, then signaling would be needed.

[RG] If this means "QoS related CT replaces MN signaling during 
[RG] handoff", given that the related resource reservation
[RG] doesn't change.

> I did not mean to imply that any changes were required in the 
> generic CT requirements (though perhaps there would need to be

[RG] QoS CT should use the NSIS resource reservation parameters
[RG] as basic input for its own QoS parameters. Whether the 
[RG] original NSIS parameters are copied or derived 
[RG] technology or domain specific parameters are used for CT 
[RG] doesn't matter if the result is as if the original NSIS 
[RG] parameters were used to establish resources at the new AR.

> Is this accurate, from the NSIS viewpoint? One case where I 
> could see it not being accurate is if there were some changes
> required behind the access router in order to obtain QoS for 
> the mobile on the new router, but perhaps there are others.

[RG] This may have to be clarified. I wouldn't expect an MN
[RG] to get involved into tunnel set up and release, should
[RG] this be the way an access network supports QoS and 
[RG] mobility. A local NSIS solution may be used within 
[RG] the access network to provide the required signaling.
[RG] But I'd expect this to be invisible to the MN. 

[RG] I think NSIS and SEAMOBY must agree how both interwork.
[RG] Besides the QoS parameter issue, an MN should be aware
[RG] of the fact whether CT is supported and whether it is 
[RG] succesful (or whether it wasn't).
[RG] To me this seems to be a loose cooperation. If NSIS and
[RG] SEAMOBY conclude to ignore each other, I'd regard both
[RG] as a waste of time with regard to wireless mobility 
[RG] combined with QoS. 

Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 15 Jul 2002 09:34:25 +0200

Hi John,

>>> The one step we could take (but not the one that was 
>>> suggested) would be to investigate into ensuring 
>>> some commonality between the formats for 
>>> encapsulating the respective data chunks (i.e. 
>>> context/NSIS parameters). Or at least, provide 
>>> for NSIS to carry CT data chunks and visa versa.

> What I suggest is that NSIS and CT progress, and since there
> is some overlap in the interest of both groups, we can
> try to ensure that whatever solutions we work on do not
> cause trouble for the different working groups.  However,
> I don't support tightly coupling the solutions.  A much
> better way would be that after CT & NSIS work is well
> along, someone could make an applicability document of
> combining both NSIS & CT  into a solution for 
> particular deployments.

Both points completely represent my expectations on a loose
but useful cooperation of NSIS and SEAMOBY. 

Regards, Rüdiger