Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

From: hammer michael <[email-masked]>
Date: Thu, 28 Sep 2000 15:28:54 -0700

Roy,

I need to be very careful what word I choose.  Session connection rather 
than path might have been more appropriate.  I believe confusion can occur 
if the type of location, registration, location, paging, etc. is not 
accurately defined.  I think that the intent of such services revolves 
about maintaining relationships between certain elements, such as between:

user/application and terminal,
terminal and network end-point,
network end-point and link end-point, etc.

The act of "registering" may mean different things at different layers and 
use different mechanisms to accomplish them.  The question for me is 
whether these are handled independently or does one mechanism attempt to 
manage multiple associations or would one type of registration trigger 
another type at a different layer?

Would SIP then manage the "presence" of a person on a terminal, where 
something else manages the "presence" of a terminal on the network?

Mike Hammer

At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
>Hi, Mike:
>
>You have made excellent points. In fact, you are in the heart of this
>problem: How the communications path(s) needs to be established as the point
>of attachment is changed during the contiguous mobility.
>
>I personally believe that SIP does not need to be involved to set up the
>communications path(s) per se.
>
>However, SIP needs to be used to set up the session: re-INVITE (to the new
>address) may need to be used.
>
>In the process, location updates, paging, etc. are also involved. If the
>location update does not have any impact in the SIP layer, I do not think
>that SIP should be aware of any change in the lower layer. For example,
>mobile IP has the power of providing location transparency of the IP layer
>(although it has some problems to meet the performance requirements for the
>real-time communications like voice).
>
>In addition to IP addresses, there are also transport addresses (e.g., UDP,
>TCP) for media. One also needs to be careful how to deal with the TCP
>connection. IP addresses change, but the TCP connections still remains the
>same. An update mechanism needs to be defined. In turn, does it mean that
>this updated information may also be propagated to the SIP layer (other
>members may also provide comments on this) because SIP does have the
>abstraction of the transport address?
>
>I have not yet talked about the link layer.
>
>I am not trying to solve the mobility problem here.
>
>All I am trying to show: If we try to analyze the situation doing an
>end-to-end analysis, we can easily see what needs to be done in each layer.
>Finally, we can answer the question: Whether or not any new work is needed
>in the SIP layer to address both discrete and continuos mobility.
>
>But you are right that we MUST keep the involvement of the SIP layer to a
>minimal level (if possible, we should avoid it) to address the mobility
>problem.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: hammer michael [mailto:[email-masked]]
>Sent: Thursday, September 28, 2000 2:41 PM
>To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [email-masked]
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
>Mobility )
>
>
>Roy,
>
>Your use of the terms "discrete" and "continuous" strike to the heart of
>the issue.  In traditional mobile networks, there is an attempt to move the
>stream of media with the terminal as it crosses cell boundaries
>(continuous).  There are many papers related to voice and mobile-IP that
>address how to move the communications path.
>
>The discrete case is more an issue of identification of the presence and
>availability of recipients and the establishment of communications to
>them.  Because names and addresses denoting physical location are often
>blurred, in essence, personal mobility involves the creation and deletion
>of recipients rather than their movement.
>
>As I understand it, SIP does not move existing communications so much as it
>destroys existing communications paths and replaces them with new ones.  In
>that respect, some of the traditional mobility issues such as handover are
>avoided, but others, e.g. location updates and paging are still needed.
>
>While the telcos reverted to addressing hardware-oriented terminal mobility
>in PCS, the softer personal mobility is still open to definition.  The same
>issues have appeared in the net world and each will need to be solved in
>their respective layers.
>
>Mike
>
>
>At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> >Hi, Mike:
> >
> >In fact, this is the precisely the test why SIP should be involved or to be
> >enhanced to support mobility (discrete + continuos) in the case of Voice,
> >chat, IM, messaging, conferencing, games, and others.
> >
> >If it is found that SIP does not need to be involved, I do not think that
> >anyone will force it to do this.
> >
> >By the way, do you not see that how SIP (RFC 2543) has taken care of many
> >aspects of users' discrete mobility? Has it not been be an excellent way of
> >involving SIP to solve a kind of mobility in the first place (what other
> >applications like H.323 is yet to support)?
> >
> >Along the same line, if people come up with the ideas that it is better to
> >enhance SIP functionality to support other aspects of mobility (if
> >alternative solutions are not there or not acceptable), I do not think that
> >we should have any objections.
> >
> >Let us keep our mind open and judge each proposal with its own merits.
> >
> >Best regards,
> >Radhika R. Roy
> >AT&T
> >
> >-----Original Message-----
> >From: Michael Thomas [mailto:[email-masked]]
> >Sent: Wednesday, September 27, 2000 7:01 PM
> >To: Henry Sinnreich
> >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning
> >Schulzrinne'; [email-masked]
> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> >Mobility )
> >
> >
> >Henry Sinnreich writes:
> >  > >what seems clear is that there are a
> >  > >number of applications which won't be able to do
> >  > >that for a variety of reasons.
> >  >
> >  > Voice, chat, IM, messaging, conferencing, games, etc., are
> >  > plenty of reasons to justify the SIP approach to mobility.
> >
> >    But what if you could do all of the same things
> >    and not need to modify or involve SIP and have the
> >    additional gain that things like http worked as well?
> >
> >                    Mike
> >
> >  >
> >  > Henry
> >  >
> >  > >-----Original Message-----
> >  > >From: [email-masked]
> >  > >[mailto:[email-masked]]On Behalf Of
> >  > >Michael Thomas
> >  > >Sent: Wednesday, September 27, 2000 8:33 PM
> >  > >To: Roy, Radhika R, ALCOO
> >  > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne';
> >  > >[email-masked]
> >  > >Subject: RE: [SIP] Attempt at summarizing current SIP
> >  > >drafts (SIP
> >  > >Mobility )
> >  > >
> >  > >
> >  > >
> >  > >I guess what I'm having a hard time with is the
> >  > >starting point that assumes that SIP based
> >  > >application mobility is Good Thing. While it's
> >  > >clear that many applications *could* design in
> >  > >mobility, what seems clear is that there are a
> >  > >number of applications which won't be able to do
> >  > >that for a variety of reasons. Assuming that those
> >  > >applications are important too, then we're already
> >  > >stuck with needing to solve for the general
> >  > >problem.
> >  > >
> >  > >Starting out with the assumption that Mobile IP
> >  > >addresses the more general problem seems
> >  > >attractive because a good solution with fast
> >  > >handoff that addresses AAA and QoS would solve
> >  > >most of the application layer problems in a
> >  > >general way rather than just a SIP specific
> >  > >way.
> >  > >
> >  > >There also seems to be an implicit assumption in
> >  > >the draft of linkage of SIP to a AAA function.
> >  > >I'm going to guess that it is along the same line
> >  > >of thinking of the DQoS gate controller idea. The
> >  > >problem I have with that is that it is in the end
> >  > >an optimization on the normal RSVP/COPS pull
> >  > >model. However, things that don't fit into that
> >  > >model still have the non-optimized way of doing
> >  > >QoS authorization. That's probably not the fault
> >  > >of this draft, but it does seem to make the entire
> >  > >draft a cart-before-horse situation.
> >  > >
> >  > >    Mike
> >  > >
> >  > >Roy, Radhika R, ALCOO writes:
> >  > > > Hi, Mike:
> >  > > >
> >  > > > I guess that SIP, as you rightly pointed out, is
> >  > >dealing with the signaling
> >  > > > mechanism in the application layer. So, SIP does
> >  > >not need to deal with L3
> >  > > > media path.
> >  > > >
> >  > > > SIP does deal with addresses of the source and
> >  > >destination(s).
> >  > > >
> >  > > > In mobile environment, the point of attachment
> >  > >(i.e., addresses) changes: 1.
> >  > > > Between the sessions (discrete mobility) and 2.
> >  > >During the session
> >  > > > (continuous mobility).
> >  > > >
> >  > > > The problem that is being addressed is: What is the
> >  > >impact in SIP layer due
> >  > > > to these two kinds of mobility.
> >  > > >
> >  > > > I guess that for discrete mobility, SIP has
> >  > >probably addressed most of the
> >  > > > problems (others may also provide comments on this).
> >  > > >
> >  > > > For continuous mobility, there may need (or may
> >  > >not??) some works in the SIP
> >  > > > layer, if any (others may also provide comments).
> >  > > >
> >  > > > However, SIP can only address the mobility related
> >  > >problems in the
> >  > > > application layer. This alone may not be enough to
> >  > >solve all problems
> >  > > > because some L3 and L2 problems may also need to be
> >  > >addressed at the same
> >  > > > time to have the complete solution.
> >  > > >
> >  > > > In any solution, SIP mobility needs to be limited
> >  > >only to the application
> >  > > > layer (not L3, L2, etc.).
> >  > > >
> >  > > > Best regards,
> >  > > > Radhika R. Roy
> >  > > > AT&T
> >  > > >
> >  > > > -----Original Message-----
> >  > > > From: Michael Thomas [mailto:[email-masked]]
> >  > > > Sent: Wednesday, September 27, 2000 12:32 PM
> >  > > > To: Lewis Karl-QA3387
> >  > > > Cc: 'Henning Schulzrinne'; [email-masked]
> >  > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts
> >  > > >
> >  > > >
> >  > > >
> >  > > > While I'm more than willing to believe that there
> >  > > > are mobility issues that SIP needs to deal with,
> >  > > > this paper seems to be positing SIP as the means
> >  > > > of initiating data sessions altogether. To my
> >  > > > mind, that's a rather bellheaded way of thinking
> >  > > > about how you do what amounts to L3 admission
> >  > > > control. In fact, the IETF already has an L3
> >  > > > admission control mechanism: RSVP. RSVP's main
> >  > > > advantage is that it follows actual network
> >  > > > topology. SIP is at a distinct disadvantage since
> >  > > > all it knows about is the signaling path which
> >  > > > in normal circumstances has nothing to do with
> >  > > > the actual data path.
> >  > > >
> >  > > > Maybe I'm misreading this whole paper, but it sure
> >  > > > looks like it to me. If my interpretation is
> >  > > > right, however, I'd like to know if the intention
> >  > > > is to signal the access routers providing the
> >  > > > L2/L3 bits using SIP instead of, say, COPS (or
> >  > > > DIAMETER). If so, I'd say that SIP truly has
> >  > > > arrived at becoming the new millenium's kitchen
> >  > > > sink if this is accepted.
> >  > > >
> >  > > >    Mike
> >  > > >
> >  > > > Lewis Karl-QA3387 writes:
> >  > > >  > I have just reviewed the Mobility Related drafts
> >  > >and am wondering if
> >  > > > anyone
> >  > > >  > is aware of the current status of
> >  > >draft-itsumo-sip -mobility-req-01. In
> >  > > >  > particular, several issues were identified such
> >  > >as Mobile IP not being
> >  > > >  > sufficient for personal mobility and location
> >  > >services, completing
> >  > > >  > registration in less than a few seconds,
> >  > >reconfiguration in milliseconds,
> >  > > >  > providing location services, support of inter
> >  > >domain soft-hand and secure
> >  > > >  > signaling. Have these issues been addressed or
> >  > >actively being worked?
> >  > > >  >
> >  > > >  > Karl
> >  > > >  >
> >  > > >  >
> >  > > >  >
> >  > > >  > -----Original Message-----
> >  > > >  > From: Henning Schulzrinne
> >  > [mailto:[email-masked]]
> >  >  >  > Sent: Monday, September 25, 2000 9:20 AM
> >  >  >  > To: [email-masked]
> >  >  >  > Subject: [SIP] Attempt at summarizing current SIP drafts
> >  >  >  >
> >  >  >  >
> >  >  >  > Given the proliferation of SIP-related drafts, I've
> >  > created a summary of
> >  >  >  > efforts at
> >  > http://www.cs.columbia.edu/~hgs/sip/drafts.html. This is
> >  >  >  > known to be incomplete, so I'd appreciate if you could
> >  > send me any
> >  >  >  > additions or corrections. (Jonathan Rosenberg provided
> >  > some of the text;
> >  >  >  > any mistakes or misrepresentations are mine.)
> >  >  >  >
> >  >  >  > It is fairly clear that there are a large number of drafts
> >  > that have not
> >  >  >  > changed materially for half a year or more. Maybe it's
> >  > time to have a WG
> >  >  >  > last call or two or ten...
> >  >  >  >
> >  >  >  > Henning
> >  >  >  > --
> >  >  >  > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> >  >  >  >
> >  >  >  >
> >  >  >  > _______________________________________________
> >  >  >  > SIP mailing list
> >  >  >  > [email-masked]
> >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
> >  >  >  >
> >  >  >  > _______________________________________________
> >  >  >  > SIP mailing list
> >  >  >  > [email-masked]
> >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
> >  >  >  >
> >  >  >
> >  >  > _______________________________________________
> >  >  > SIP mailing list
> >  >  > [email-masked]
> >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
> >  >  >
> >  >  > _______________________________________________
> >  >  > SIP mailing list
> >  >  > [email-masked]
> >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
> >  >  >
> >  >
> >  > _______________________________________________
> >  > SIP mailing list
> >  > [email-masked]
> >  > http://lists.bell-labs.com/mailman/listinfo/sip
> >  >
> >  >
> >
> >_______________________________________________
> >SIP mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/sip
> >
> >_______________________________________________
> >SIP mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 29 Sep 2000 15:56:01 +0100

Have struggled with the same, and believe

>network end-point and link end-point, etc.

would be worth an I-D all by itself.

Henry

>Sent: Thursday, September 28, 2000 11:29 PM