Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26316 for ; Mon, 8 Jul 2002 13:22:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05845; Mon, 8 Jul 2002 13:18:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05735 for ; Mon, 8 Jul 2002 13:18:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26034; Mon, 8 Jul 2002 13:17:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68HHE901854; Mon, 8 Jul 2002 13:17:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 13:17:13 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Hemant.Chaskar@nokia.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Mon, 8 Jul 2002 13:17:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C226A3.49C8C2B6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/plain; charset="iso-8859-1" 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:kempf@docomolabs-usa.com] > Sent: July 8, 2002 12:39 > To: Hemant.Chaskar@nokia.com; Kenward, Gary [WDLN2:AN10:EXCH]; > seamoby@ietf.org; nsis@ietf.org > 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: > To: ; ; > 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:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; '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 > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Re: = draft-westphal-nsis-qos-mobileip-00.txt

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:kempf@docomolabs-usa.com= ]
> Sent: July 8, 2002 12:39
> To: Hemant.Chaskar@nokia.com; Kenward, Gary = [WDLN2:AN10:EXCH];
> seamoby@ietf.org; nsis@ietf.org
> 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: <Hemant.Chaskar@nokia.com>
> To: <gkenward@nortelnetworks.com>; = <seamoby@ietf.org>; <nsis@ietf.org>
> 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:gkenward@nortelnetwor= ks.com]
> > Sent: 08. July 2002 12:00
> > To: 'seamoby@ietf.org'; '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
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis=
> >
> > = _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C226A3.49C8C2B6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby