Subject: Re: [Sip] SIP Traceroute using Max-Forwards

From: "Arjun Roychowdhury" <[email-masked]>
Date: Mon, 19 Aug 2002 16:51:26 -0400

Taking the standard Killroy header forward, if you are planning to address 
a more general scope, probably another option may
be to defined an XML body with tags where different servers could insert 
one or more parameters. 
eg.
<server>
<ip> a.b.c.d</ip>
</server>
<server>
<ip> c.d.e.f</ip>
<load> 75 </load> 
</server>

The amount of information inserted could vary depending on what the 
servers want to insert as well as the minimal/maximal information
requested by the original sender. The tags could be well defined (at least 
a subset) to specify a minimum profile.

I am not sure if the above would be considered an overkill -> comments 
welcome.

If operators decide not to provide information, well, then its their 
prereogative. This defines a mechanism to share 'characteristics'
in a well defined way. 

I would also note that 'capability discovery' or 'path discovery' has an 
assumption that nodes participating will contribute information.
Its similar to saying 'will traceroute work if a firewall blocks ICMP ? ' 
-> It will not - because the network layout decided so. I am not
sure if these concerns need to be intertwined with specifying a mechanism. 

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066

Dean Willis <[email-masked]>
Sent by: [email-masked]
08/19/2002 04:39 PM

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        Re: [Sip] SIP Traceroute using Max-Forwards

[email-masked] wrote:

> 
>
>>I think it would be a good exercise to look at
>>the requirements for this sort of thing (over in
>>SIPPING) and see if we can move towards a nice,
>>safe, and secure way of solving the general class
>>problem.
>> 
>>
>
>I'm wondering just how the general class of problem here is relevant to 
SIP
>in itself. The route among proxies is going to be selected at the
>application level by some combination of systems of which CPL and user
>preferences are early representatives. Just what could SIP supply in this
>application domain beyond the Kilroy-type headers described previously.
>Certainly the selection of headers to exercise various aspects of the
>application goes far beyond anything that could profitably be discussed 
in
>SIPPING.
I suspect even standardized kilroys would be useful. Many questions 
abound -- for example, what are the security issues, when many operators 
insist that completely hiding their topologies from discovery is a 
critical security function? Can the kilroys-type-headers be spoofed? How 
do you debug routing problems that span multiple operator environments? 
How do you poliely ask for the service nodes to add headers? How do you 
insist?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Sean Olson <[email-masked]>
Date: Mon, 19 Aug 2002 14:15:16 -0700 (PDT)

I think these concepts can be separated. 

(1) You want to convey the identity of the servers
    along the path.

(2) You also want to convey the capabilities of 
    those servers. 

(3) Finally you may want to convey various 
    performance metrics (like load) about those
    servers.

The first is probably best handled by a simple
extension header introduced into requests.
   Traceroute: servername
along with
   Require: traceroute

The second is best handled by a combination of 
existing headers (Accept:, Accept-Language:, etc.)
and possibly a new XML payload for OPTIONS. Make
that multipart/mixed and throw in SDP(ng) for more
information.

The third is probably best handled out-of-band using
something like SNMP.

/sean

> sure if these concerns need to be intertwined with

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com