Subject: RE: [SIP] SIP and soft hand-off

From: "Roy, Radhika R, ALARC" <[email-masked]>
Date: Fri, 14 Apr 2000 20:39:56 -0400

Hi, Everyone:

My comments are as follows:

1. We are extending SIP to support mobility in the application layer. So,
SIP WG is the right place. The SIP WG is the only group that knows what to
do the SIP protocol in the application layer.

Let me provide another analogy. We are extending SIP to support QOS. That
does not mean that extension of SIP has to be done in the QOS WGs (DiffServ,
MPLS, etc).

Only SIP WG can ensure whether the extension of SIP to support mobility
remains within the framework SIP architecture because they are the expert in
this application layer protocol (not mobile IP or other WGs).

2. For other points, the technical justifications and contributions will
proof the fact. No personal opinion will help unless it is justified from
technical point of view. (Personally, I would be happy to do as much less
work as we could do to support mobility in SIP.)

Hope this will clarify further.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 14, 2000 4:11 PM
To: Roy, Radhika R, ALARC
Cc: [email-masked]
Subject: RE: [SIP] SIP and soft hand-off

Comments below:

Radhika wrote:
>Chris:

>Now there are internet-drafts related to SIP mobility as well.
>
The SIP WG charter does not currently include mobility solutions in
it's scope. However mobility support will be a key aspect of evolving
networks and there is a specific WG in the IETF which deals with it -
Mobile IP.

>Let me clarify: If the network point of attachment is NOT changed, there is
>almost (some non-real-time mobility management may be needed) no need to do
>anything in the application layer (e.g., SIP, H.323). But it is only a
>special situation.
>
>In many situations, it may not be possible. We are addressing those from
>mobility management point of view. There can be two aspects of this: 
> 1.Should we consider hand-off in the appln layer? 
No. 

>2. Should we consider NO handoff in the appln layer?
The Mobile IP WG is currently debating multiple I-Ds that propose
handoffs at the network layer. If at all handoffs are to be moved to
upper layers (from link/physical layers) then it may be optimal to do
it at the network layer. 

-Basavaraj

>
>I hope that we could agree that the mobility solution would be transparent
>to the application layer (we could save our time)!
>
>Best regards,
>Radhika

_______________________________________________
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: "David Oran" <[email-masked]>
Date: Tue, 18 Apr 2000 17:10:22 -0400

In the small hope this will shed light rather than heat...

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy, Radhika R, ALARC
> Sent: Friday, April 14, 2000 8:40 PM
> To: [email-masked]
I think there's a terminology problem here. When layer 2 people talk about
mobility it means something different than when layer 3 people talk about
mobility, and still something different when layer 7 people talk about
mobility. What is common however, is the need to keep an application happy
in the face of changes in the underlying network connectivity.

- For layer 2 folks, this means keeping the mobility transparent to layer 3
and above in order to provide what looks like a homogenous topology to the
algorithms and protocols which run IP and other global protocols in layers
3, 4 and above. This of course works well in a single administrative domain,
scales only so far, and depends on pretty tight timing and a fair amount of
state.

- For layer 3 folks, this means keeping the logical connectivity seen by the
transport and above constant in order to keep the transport protocols
(especially TCP) happy. By extension this is needed to keep applications
which view transport failure as fatal or semi-fatal from thinking the world
has fallen apart when an IP address changes.

- For layer 7 folks, it just means that the application protocol can deal
with changes in connectivity, network address, and even in some cases,
complete disconnection from the network for extended periods of time (poster
child for this is disconnected file systems like Andrew and DFS, and offline
WEB caching by browsers).

What is (sadly) common among these is only:
1. each assumes that the layers above absolutely positively need
transparency or the world comes crashing down around their ears.
2. each assumes that the layers below can only deal with a subset of the
likely mobility scenarios, and hence are absolutely, positively sure that
they can't depend on the lower layer for performance, robustness, or
scalability reasons.

In the case of SIP, I believe the motivation for doing something to support
mobility directly is driven by:
a) not wanting to depend on Mobile IP in all devices and network
infrastructures. Beyond this, I suspect the dog-leg routing and tunneling
needed by at least the MobileIPv4 approach is viewed as having significant
performance problems for the kind of real time traffic sessions set up by
SIP
b) wanting to have "global" mobility - completely independent of current
network connectivity, administrative boundaries, etc.
c) wanting to potentially deal with mobility at a semantic level above that
of the IP host (e.g. moving a media stream from one device to another).

I don't want to make a value judgement on the validity or relative
importance of these motivations, except to make the observation that the
end-to-end argument has shown again and again its power and general
superiority. It's been true for error control, flow/congestion control,
security, and many of the "ubiquitous" features of computer networks. For me
that says that applications wanting to support mobility in a flexible and
general way will want to have their own mechanisms, but to exploit lower
layer mechanisms AS OPTIMIZATIONS when they are available.

> does not mean that extension of SIP has to be done in the QOS WGs
This is NOT precisely true. We specifically did *NOT* extend SIP to support
QoS. That would have been a bad thing to do. What we did instead is allowed
SIP to convey information used to control the lower layer QoS mechanisms,
and to synchronize session establishment with results of QoS signaling
operations.
Perhaps we can use this as guidance for at least the kind of mobility
mentioned in (b) above.

> this application layer protocol (not mobile IP or other WGs).
This depends on just what one views as the scope of "mobility" as seen by
SIP. God help us if we try to use SIP as a general hammer to pound on the
mobility nail. I can easily see how folks not close to SIP or its domain of
applicability could draw scary conclusions.

> Hope this will clarify further.
Ditto for my feeble attempts...
Dave Oran.