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 KAA19758 for ; Thu, 11 Jul 2002 10:51:43 -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 KAA12668; Thu, 11 Jul 2002 10:49:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12577 for ; Thu, 11 Jul 2002 10:49:39 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19662; Thu, 11 Jul 2002 10:48:45 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BEl7M29024; Thu, 11 Jul 2002 10:47:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 10:47:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C05@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Geib, Ruediger'" , kempf@docomolabs-usa.com, Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 10:47:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228E9.D1A64AE4" 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_01C228E9.D1A64AE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ruediger: Concerning the comment that CT use the "original NSIS parameters": - CT is not a service establishment protocol; it tranports forwarding context, not service description parameters. Some of the forwarding context *may* be the original service = description parameters, but many *may* be derived values that allow a more representative description of the AR forwarding context. - The issue is rather moot, because neither Seamoby nor NSIS are chartered to define what the signalling parameters or forwarding context are. To say that there should be some commonality is=20 of little import, as neither group can analyze the feasibility = and impact of such a statement. - For the two groups should discuss the common parameters would be = a violation of the respective charters. I think that this is an excellent idea, but I believe it will have to take place outside of the NSIS/Seamoby wgs, and I suggest that it would be best if we knew what the = CT/NSIS=20 protocols were - at the very least, we can proceed with the definition=20 of the protocols. Regards, Gary > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: July 11, 2002 04:24 > To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com; > rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00. txt >=20 >=20 > Hi James >=20 > > The point I was trying to make is that given CT of QoS=20 > > context succeeds, NSIS signaling at the new access subnet is > > unnecessary. Thus, it could be viewed as a kind of=20 > > optimization. If CT fails, then signaling would be needed. >=20 > [RG] If this means "QoS related CT replaces MN signaling during=20 > [RG] handoff", given that the related resource reservation > [RG] doesn't change. >=20 > > I did not mean to imply that any changes were required in the=20 > > generic CT requirements (though perhaps there would need to be > > some changes in the QoS specific context definition). >=20 > [RG] QoS CT should use the NSIS resource reservation parameters > [RG] as basic input for its own QoS parameters. Whether the=20 > [RG] original NSIS parameters are copied or derived=20 > [RG] technology or domain specific parameters are used for CT=20 > [RG] doesn't matter if the result is as if the original NSIS=20 > [RG] parameters were used to establish resources at the new AR. >=20 > > Is this accurate, from the NSIS viewpoint? One case where I=20 > > could see it not being accurate is if there were some changes > > required behind the access router in order to obtain QoS for=20 > > the mobile on the new router, but perhaps there are others. >=20 > [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=20 > [RG] mobility. A local NSIS solution may be used within=20 > [RG] the access network to provide the required signaling. > [RG] But I'd expect this to be invisible to the MN.=20 >=20 > [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=20 > [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=20 > [RG] combined with QoS.=20 >=20 > Regards, R=FCdiger >=20 ------_=_NextPart_001_01C228E9.D1A64AE4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

Ruediger:

  Concerning the comment that CT use the "original NSIS parameters":

        - CT is not a service establishment protocol; it tranports
       forwarding context, not service description parameters. Some
       of the forwarding context *may* be the original service description
       parameters, but many *may* be derived values that allow a more
       representative description of the AR forwarding context.

     - The issue is rather moot, because neither Seamoby nor NSIS are
       chartered to define what the signalling parameters or forwarding
       context are. To say that there should be some commonality is
       of little import, as neither group can analyze the feasibility and
       impact of such a statement.

     - For the two groups should discuss the common parameters would be a
       violation of the respective charters. I think that this is an excellent
       idea, but I believe it will have to take place outside of the NSIS/Seamoby
       wgs, and I suggest that it would be best if we knew what the CT/NSIS
       protocols were - at the very least, we can proceed with the definition
       of the protocols.

Regards,
Gary

> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Sent: July 11, 2002 04:24
> To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com;
> rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
>
>
> 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
> > some changes in the QoS specific context definition).
>
> [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
>

------_=_NextPart_001_01C228E9.D1A64AE4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby