Subject: RE: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt)

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Sun, 25 Jan 2004 06:20:38 -0600

> Probably locators will be hardcoded in less places than today, so they will
> be simpler to renumber and IDs will be hardcoded in some of the places that
> ip are used today and perhaps in many others, since they will be used for
> recognizing endpoints in apps and filters, acls and so on
  
If so,it's good. But, for example, SIP hardcodes locators instead of DNS 
names. As per discussions in ietf-aulli, apps folks attributes it to lack 
of access to naming service and reduced delay (in terms of lookup latency.)
So, in future, we can expect more such locator hardcoding at ULP.
 
> So renumbering locators maybe simpler than renumbering IPs today, but
> renumbering IDs may be quite complex since it may require lots of manual
> configuration
 
it looks simple as i read baker-ipv6-renumbering. But, yaa...reading is 
different than practical deployment ;-) 
 
> IMHO, stable ids are good
 
Other than the renumbering reason, stable ID helps in solving the 
address ownership problem. HIP like stable IDs can be used to avoid
address hijacks and origin misconfigurations; as it provides self
verifying capability (i.e. we don't need to depend on costly PKI or
CA to authorize the origin prefix.) The assumption being ID and locator 
mapping is secure.

---

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Sun, 25 Jan 2004 17:59:01 -0600

>It is not exactly "hardcoding". SIP payloads carry the IP addresses to
>be used for initiating media sessions, but the protocol also has
>provisions for changing these addresses if the SIP agent's location
>happens to change. It is much easier to move a session to a new location
>by telling the peer about the new location than by updating a name
>service and hoping that the peer will find out. 
 
But, the bottleneck is shifted to STUN/Teredo servers instead of
name servers (with the caveat that it doesn't allow all types of 
traversal through NAT. esp TCP.)

>In any case, there is more than performance at stake. We must also to
>consider privacy. A SIP agent will only reveal its current location to
>the peers with whom it agrees to establish a session. This is very
>different from publishing a mapping between identifier and location in a
>globally accessible name service.
 
we can still maintain privacy in such a global mapping service. It 
depends on the design of the id/loc mapping service (but it depends
on the type of identifier; HIT/HIP can provide anonymity.) Also,
privacy can further be enhanced by having a stack of identifiers 
to route packets. In any case, a HIP related RG will concentrate
on these issues.
 
But, I would very much like the id/loc mapping to mirror SIP 
like design; rather than new overlay infrastrcuture (DHT
seems costly from a management perspective.)

>Not to say that SIP has got everything right. The payload format only
>allows for one IP address per media stream, which is problematic when
>the host is multi-homed or multi-addressed.
 
so, we need a new SDP description?

---

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Sun, 25 Jan 2004 19:23:06 -0600

> Christian,
 
 I am not christian ;-)
 
> How does SIP differ conceptually at the application 
> layer from what MIPv6 does at the IP layer?
 
SIP, not just provides terminal mobility like MIP, 
but also session and service mobility. then, it 
also supports presence etc. In terms of terminal 
mobility,MIP is better when compared to SIP ( as 
SIP targets IP telephony and not suitable for 
TCP-based applications.)

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 25 Jan 2004 17:54:58 -0800

> Christian,
> 
> How does SIP differ conceptually at the application layer from what
> MIPv6 does at the IP layer?
> 
> Eliot

SIP separates signaling from media transmission. I will invite you to a
session, the signaling traffic will pass through the system of SIP
servers, but the media should flow directly between the two "end
points". In contrast, MIPV6 handles just one kind of traffic; packets
may flow directly between the current locations, or it may remain "non
optimized" and flow through the home agents.

SIP separates the logical identity from the media endpoints. It is
perfectly reasonable to have a session between two logical identities,
say Alice and Bob, but to have the media flow between different pairs of
cameras and screens, mikes and speakers, etc. The choice of the media
endpoint is based on the application, e.g. choose between headset on my
mobile phone and loud speakers on my stereo. In contrast, MIPv6 assumes
that the COA is 'equivalent' to the HA, and that any choice is based
purely on connectivity considerations.

SIP includes an explicit negotiation of the session parameters. The
negotiation is mostly based on the capacities of the end points, such as
the medias and codecs supported by the end point, but it may also take
into account transmission issues, e.g. what is the available bandwidth.
In contrast, MIPV6 does not perform any such negotiation.

-- Christian Huitema