Subject: RE: [Mipshop] GIST for 802.21

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 3 Aug 2006 14:45:07 -0400

Hi Robert, Johne, et. al,

Thanks for your explanations it definitely helped clear up some of the
confusion.  I think that you should revise some of the wording in the
GIST draft to make sure that the same question does not come up again.

Now for the MIH (802.21), I guess the key statement that you made was
that "the path-coupled functionality in GIST is not intended for
end-to-end signalling.  However, the proposal for MIH is *not* to use
the functionality
that is specific to the path-coupled case."

I know that you are currently working on the Problem Statement (and I am
going to send some comments out on that shortly), but can you please
tell me what GIST functionality will NOT be used for MIH?

Akbar

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]] 
Sent: Wednesday, August 02, 2006 6:06 AM
To: [email-masked]; [email-masked]; Rahman,
Akbar; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] GIST for 802.21

hi Akbar, John, James, all, ...

having written the offending words, i can try to explain their
significance.

When we started on the GIST work, as john says, we were focussed
quite specifically on the path-coupled signalling case, where
you want some signalling messages to pass between nodes along the
path taken by a data flow. In that context - i.e. when you have a
data flow in the picture - you also have to be aware that there is
other signalling which involves only the flow endpoints, including 
for example the signalling that sets the flow up in the first place
(e.g. SIP or whatever).
It turns out that the requirements on this end-to-end signalling
are quite different from the along-the-path signalling, and it has
been important to be clear about which part of the overall problem
GIST is attempting to solve. Hence the statement: "the path-coupled
functionality in GIST is not intended for end-to-end signalling".
However, the proposal for MIH is *not* to use the functionality
that is specific to the path-coupled case.

There is *no* intended exclusion to say that GIST is never intended
for any type of upper layer signalling. Indeed, one person's upper
layer is another person's infrastructure, so I'm not sure how such
an exclusion could meaningfully be made. The MIH application space
is not an example of path-coupled signalling, so the distinction
between end-to-end and along-the-path signalling in the GIST spec intro
just doesn't arise in the first place. In the general .21 problem
space, it is of course important to distinguish the MIH signalling
from other types of signalling, such as the mobility protocols
themselves; indeed, the .21 documents do precisely that.

In any case, it's probably better to think of the question the
other way round: is the functionality provided by GIST (with the
extensions discussed in our solution draft) a good match to the
functionality required by MIH signalling (as discussed in the 
problem statement and amplified in the design considerations draft).
If it is a match, then IMHO it's a good basis for further work.

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 02 August 2006 06:27
> To: [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Mipshop] GIST for 802.21
> 
> 
> Hi all, 
> 
> Quick comment on this section of the GIST draft, as I think there is a
> misunderstanding here:
> 
> GIST says:
> 
> > - This specification concentrates mainly on path-coupled signaling,
> >   which involves network elements which are located on the 
> path taken
> >   by a particular data flow, possibly including but not 
> limited to the
> >   flow endpoints.  Indeed, there are almost always more than two
> >   participants in a path-coupled signaling session, 
> although there is
> >   no need for every node on the path to participate.  Path-coupled
> >   signaling thus excludes end-to-end higher-layer application
> >   signaling.
> 
> For MIH, you should interpret this to mean that there is a 
> MIH signaling
> application that covers end-to-end application signaling, while GIST
> provides the transport.
> 
> In terms of MIH, I think that the MIH signaling could/should run
> something
> like this:
> 
> MN <-> AP/AR <-> MIH entity
> 
> GIST could be run over the MN-AR and between the AR-MIH; 
> however, there
> are
> cases that James has brought-up where the AR would be acting like a
> proxy,
> so GIST could be run between the AR-MIH.  The MIH signaling 
> would be run
> between the MN-MIH, if I understand things correctly.
> 
> In summary, the above paragraph in GIST is just saying that GIST does
> transport,
> and some other protocol above it does the specific application
> signaling,
> which, in the 802.21 case would be the MIH signaling.
> 
> Does this clear things up?
> 
> John
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
>

Akbar Rahman  
Principal Engineer, Systems
InterDigital Canada Ltee
1000 Sherbrooke Street West
10th Floor
Montreal, Quebec H3A 3G4
Tel.: +1 514.904.6270
Fax: +1 514.904.6344
Email: [email-masked]
http://www.InterDigital.com

 This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient.  Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

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

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 3 Aug 2006 22:11:15 +0100

hi akbar, all,

> From: Rahman, Akbar [mailto:[email-masked]] 
> Sent: 03 August 2006 19:45
> To: Hancock, Robert; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]

point taken :-)

> that is specific to the path-coupled case."

exactly.

> tell me what GIST functionality will NOT be used for MIH?

basically the critical aspect is the subset of GIST that is
specific to the path-coupled MRM. (you can find basically this
statement on page 10 of draft-hancock-mipshop-gist-for-mih-00,
although for reasons which escape me we referred to it as
'flow coupled' in that document).

what that amounts to is a particular set of rules for managing 
the initial Query message, a particular format for message 
routing information, and a set of algorithms for reacting to
changes in topology. it may be necessary to develop replacements
for these for the MIH case, depending on how the responsibility 
for signalling node discovery gets apportioned between the 
MIH 'service level' protocols and GIST (see again the discussion
in section 3 of our solution proposal).

cheers,

robert h.

>  This e-mail is intended only for the use of the individual 
> or entity to which it is addressed, and may contain 
> information that is privileged, confidential and/or otherwise 
> protected from disclosure to anyone other than its intended 
> recipient.  Unintended transmission shall not constitute 
> waiver of any privilege or confidentiality obligation. If you 
> received this communication in error, please do not review, 
> copy or distribute it, notify me immediately by email, and 
> delete the original message and any attachments. Unless 
> expressly stated in this e-mail, nothing in this message or 
> any attachment should be construed as a digital or electronic 
> signature.
>