Subject: RE: [Mipshop] GIST for 802.21

From: <[email-masked]>
Date: Wed, 2 Aug 2006 07:32:12 +0300

Akbar,

>I had some good conversations with Robert and am getting a 
>better understanding of GIST.  I still have one fundamental 
>question though.
>The latest GIST draft (draft-ietf-nsis-ntlp-10) describes GIST as
>follows:
>
>
> - 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.
>
> - In the context of path-coupled signaling, examples of state
>   management include network resource reservation, firewall
>   configuration, and state used in active networking; 
>examples of state
>   monitoring are the discovery of instantaneous path properties, such
>   as available bandwidth or cumulative queuing delay.  Each of these
>   different uses of signaling is referred to as a signaling
>   application.

I'm on vacation (back next week) so I am keeping this short.

NSIS was initially chartered to develop an on-path signaling solution.
In developing
this, we found that with minor changes, off-path signaling can be
supported.  We are
in the process of updating our charter to support this as well.  

There has been some on-going work on this, see:
http://www.ietf.org/internet-drafts/draft-hancock-nsis-pds-problem-03.tx
t
This has WG consensus to be added to the charter.

>What confuses me is that MIH (802.21) is an end-to-end higher 
>layer application protocol.  So from the above definition it 
>seems that it is specifically excluded from using GIST (i.e. 
>read the last sentence of the first paragraph).  Any insight 
>that you could shed on this issue would be very helpful to me.

I would create a MIH signaling application running over GIST.  The MIH
Signaling Application would have all of the MIH messages, etc. GIST
would
just provide the transport.  I think Robert's draft:
http://www.ietf.org/internet-drafts/draft-hancock-mipshop-gist-for-mih-0
0.txt should try to address these issues.

As a reference, we are working on NAT / FW signaling in NSIS.  NATs and
FWs are 
transparent elements, located on the data path.  GIST has mechanisms to
discover
the these elements.  While the MIH function may not be on the datapath,
similar
discovery mechansisms that are used to discover NATs & FWs can be used.
I think
that the MIH signaling application just would have to specify some of
the details 
of this, and that is the point to discuss, IMO. I think that GIST should
be able
to handle the MIH requirements.

John

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 2 Aug 2006 11:06:17 +0100

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:
> 
> 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
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 3 Aug 2006 15:25:35 -0400

Hi, Akbar:
 
In addition, did you also get the feeling to differentiate between the two
types of end-to-end signaling stead as follows?:
 
1. End-to-End signaling between the applications. For example, SIP will
signaling all QOS parameters between the source and the destination
applications (e.g., source codec-to-destination codec).
 
2. End-to-end signaling between the two source and destination network
nodes. For example, source and destination SIP phone may be connected
between the respective routers via LANs.
 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Rahman, Akbar
Sent: Thu 8/3/2006 2:45 PM
To: Hancock, Robert; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] GIST for 802.21

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 4 Aug 2006 09:45:00 -0400

Let's try to avoid getting into a circular argument.  The main point is
that the protocol has to support different types of end points as this
is clearly stated in the Problem statement.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Friday, August 04, 2006 9:42 AM
To: Rahman, Akbar; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] GIST for 802.21

There's not supposed to be anything in the protocol itself that cares
what type of node the MIHF is within.

Best Regards,
Michael 

-----Original Message-----
From: ext Rahman, Akbar [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 6:27 AM
To: Roy, Radhika R.
Cc: [email-masked]
Subject: RE: [Mipshop] GIST for 802.21

Hi Radhika,

I think that you are right in that in general there are different types
of end to end signaling.  For MIH (802.21) there is for example
different types of end points:

- Type 1: Mobile Node to MIH Network Peer
- Type 2: Mobile Proxy (e.g. WLAN AP or cellular BS) to MIH Network Peer

This definitely has to be considered by GIST or any other transport
protocol that is proposed for MIH.

-----Original Message-----
From: Roy, Radhika R. [mailto:[email-masked]]
Sent: Thursday, August 03, 2006 3:26 PM
To: Rahman, Akbar; Hancock, Robert; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] GIST for 802.21

Hi, Akbar:
 
In addition, did you also get the feeling to differentiate between the
two types of end-to-end signaling stead as follows?:

 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Rahman, Akbar
Sent: Thu 8/3/2006 2:45 PM
To: Hancock, Robert; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] GIST for 802.21

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."

Akbar

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.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 7 Aug 2006 09:44:56 +0100

hi,

i'm not sure that there should be an issue here...

- the protocol has to support different endpoint types
  (as the problem statement says)

- a valid engineering solution to that problem is to make
  the protocol independent of the endpoint type

i suspect that there is a fundamental distinction between
'towards-the-terminal' and 'away-from-the-terminal' messages,
but apart from that, the transport design shouldn't depend 
on where the messages are actually ending up.

robert h.

> From: Rahman, Akbar [mailto:[email-masked]] 
> Sent: 04 August 2006 14:45
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 7 Aug 2006 11:00:45 -0400

Hi Alper,

I agree with your point below that the current MIH problem statement is
"too high level. It does not answer many questions, and now we need to
take
it from there......."

As I said during the IETF meeting in Montreal, we should try to avoid
solving other problems beyond the current need for
discovery/transport/security of MIH messages.  It is true that other
requirements and issues may arise in the future but first let's get
focused on solving the MIH issue and not try to come up with a "meta
solution" that solves everything.

Akbar

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Monday, August 07, 2006 8:34 AM
To: 'Hancock, Robert'
Cc: [email-masked]
Subject: RE: [Mipshop] GIST for 802.21

Hi Robert,

> - i had always understood that ES/CS/IS were fundamentally
> differentiated from each other by their different roles in the .21
> architecture, 

I think so too.

> rather than their message transport requirements. so it

I think the transport requirements (whatever they end up to be) would be
affected by your former point.

> might be dangerous at this stage to hard-code assumptions about those
> requirements into the protocol design. for example, suppose in the
> future that there is a value in sending a large message (e.g. with a
> couple of certificates or something) from the CS node in the network;
it
> would be bad if the protocol architecture forced that such messages
> could only come from the IS node.

I'm hoping we can clearly separate configuration and information
delivery
(IS) from ES and CS. Maybe we should look at some scenarios.

> - if you want to use different transports for different services, then
> you quite likely end up with parallel discovery mechanisms. 

I'm not sure if different transports imply different discovery
mechanisms. I
think this has to do more with the location of the end-points,
irrespective
of the protocols used to reach them. For example, depending on the
discovery
mechanism, even if the transports and the server nodes are different,
same
discovery mechanism may be able to help.

> conversely,
> as was discussed in the last meeting, the model of MIH services being
> used by .21 is that that server capabilities are negotiated in-band
> after initial discovery - but then one has another question about what
> are the tranport requirements for those negotiation messages
themselves,
> which are not ES/IS/CS at all.
> 
> i'm hoping that the problem statement will cover the overall transport
> requirements for all the MIH services, and also the meta-requirement
> that different services may have different needs which have to be
> accommodated efficiently. 

I agree. I've looked at the .21 requirements document and found it to be
"too high level." It does not answer many questions, and now we need to
take
it from there.......

> however, i'm not sure that it is a good idea
> to split the problem up too rigidly at this point.

I agree. But in fact I was not asking for that. I was just asking, now
that
people are also proposing GIST for 802.21, I was wondering what parts of
the
.21 problem space they think GIST should be used.

Regards,

Alper

> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: 03 August 2006 21:11
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked];
> > [email-masked]
> > Cc: [email-masked]
> > Question: which one(s) of the MIH protocols are we
> > considering GIST for?
> > (ES, CS, IS)?
> >
> > Alper
> >
> >
> > > Sent: Thursday, August 03, 2006 8:44 AM
> > > To: [email-masked]; [email-masked];
> > > Junghoon,
> > > >From the explanation about the GIST by John, I can not find
> > > >any clear issue/obstacle about the possibility in utilizing
> > > >the GIST for the transporting the MIH protocol under
> > > >considering the MIH communication model.
> > > >I might give more detailed feedback about the considerable
> > > >points in adopting GIST for MIH transport after further
> > > >exploring the GIST world.
> > >
> > > Great - let us know.  Also, as an FYI - GIST is in IETF last call,
> > > if anyone wants to send comments, please do so. Either post them
> > > to the NSIS list or send them to Robert / myself.
> > >
> > > thanks,
> > > John
> > >

 
Akbar Rahman  

 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.

---

From: Sam Xia <[email-masked]>
Date: Tue, 08 Aug 2006 09:27:49 +0800

Hi, all
      I think Akbar is right. We should focus on
discovering/transportationg/security of MIH.

 Best Regards, Sam Xia 

> 
>    1. RE: GIST for 802.21 (Rahman, Akbar)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 7 Aug 2006 11:00:45 -0400
> From: "Rahman, Akbar" <[email-masked]>
> To: "Alper Yegin" <[email-masked]>
> Cc: [email-masked]
> Message-ID:
> 	
> <[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi Alper,
> 
> 
> I agree with your point below that the current MIH problem 
> statement is "too high level. It does not answer many 
> questions, and now we need to take it from there......."
> 
> As I said during the IETF meeting in Montreal, we should try 
> to avoid solving other problems beyond the current need for 
> discovery/transport/security of MIH messages.  It is true 
> that other requirements and issues may arise in the future 
> but first let's get focused on solving the MIH issue and not 
> try to come up with a "meta solution" that solves everything.
> 
> 
> Akbar
> 
> 
> I think the transport requirements (whatever they end up to 
> be) would be affected by your former point.
> 
> I'm hoping we can clearly separate configuration and 
> information delivery
> I'm not sure if different transports imply different 
> discovery mechanisms. I think this has to do more with the 
> location of the end-points, irrespective of the protocols 
> used to reach them. For example, depending on the discovery 
> mechanism, even if the transports and the server nodes are 
> different, same discovery mechanism may be able to help.
> 
> 
> > conversely,
> I agree. I've looked at the .21 requirements document and 
> found it to be "too high level." It does not answer many 
> questions, and now we need to take it from there.......
> 
> > however, i'm not sure that it is a good idea to split the 
> problem up 
> > too rigidly at this point.
> 
> I agree. But in fact I was not asking for that. I was just 
> asking, now that people are also proposing GIST for 802.21, I 
> was wondering what parts of the
> considering GIST 
> > > for?
> > > > >From the explanation about the GIST by John, I can not 
> find any 
> > > > >clear issue/obstacle about the possibility in 
> utilizing the GIST 
> > > > >for the transporting the MIH protocol under 
> considering the MIH 
> > > > >communication model.
> > > > >I might give more detailed feedback about the 
> considerable points 
> > > > >in adopting GIST for MIH transport after further exploring the 
> > > > >GIST world.
> > > >
>  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.
> 
> 
> 
> ------------------------------
> 
> End of Mipshop Digest, Vol 28, Issue 12
> ***************************************
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 10 Aug 2006 11:51:32 +0100

hi all,

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: 10 August 2006 06:51
> To: Hancock, Robert
> Cc: Alper Yegin; [email-masked]
> Subject: Re: [Mipshop] GIST for 802.21
> 
> 
> Hi Robert and Alper,
> 
> On Mon, Aug 07, 2006 at 11:14:23AM +0100, Hancock, Robert wrote:
> > hi alper,
> >
> > that seems like a simple question, but actually I am not sure that
it
> > is.
> > architecture, rather than their message transport requirements. so
it
> > couple of certificates or something) from the CS node in the
network; it
conversely,
themselves,
> As a result of 802.21 Letter Ballot #1 comment resolution, capability
> discovery messages which belong to "System Manegement" category in
> 802.21/D01 will belong to "Command Service" category in the next
> version.

ok, i think i understand. but doesn't that mean that every node will
have
to support the Command Service in order to be able to carry out these
system management operations? does this mean that it is impossible to 
have (for example) the Information Service and Command Service on
separate nodes? Or is it possible to be in communication with multiple
instances of the Command Service?

robert h.

> Yoshihiro Ohba