Subject: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Apr 2014 11:44:26 +0000

Hi,

We've submitted a new draft, draft-holmberg-dispatch-iotl-00.

The draft defines a new SIP URI parameter, which can be used to associate a SIP URI with the end of a so called traffic leg, which is a specific part of a signaling path (see more in the draft for details). This information is very important in scenarios where the signaling traverse different operator networks, where a user can be located in its home network or in a visited network (in case of roaming), etc.

The draft is needed for 3GPP, but we've tried to write it in a way so that it can also be applied to other environments.

http://www.ietf.org/id/draft-holmberg-dispatch-iotl-00.txt

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 28 Apr 2014 11:25:28 -0400

> From: Christer Holmberg <[email-masked]>

> We've submitted a new draft, draft-holmberg-dispatch-iotl-00.

Interesting...

Why is "iotl" listed as having no predefined values in section 7:

   7.  IANA Considerations

   [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this
   document.]  This specification adds one new value to the IANA
   registration in the "SIP/SIPS URI Parameters" registry as defined in
   [RFC3969].

         Parameter Name  Predefined Values  Reference
         ____________________________________________
                   iotl      NO             [This RFC]

while section 5.2 gives five predefined values, which seem to be the
only values that are expected to be used.  (Though the BNF provides
for extension values.)

 iotl-value    = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA"
                 / "homeA-visitedA" /" visitedA-homeB" / gen-value

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Apr 2014 15:36:44 +0000

Hi Dale,

It may be a mistake. I'll look into it at the office tomorrow.

Thanks!

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Interesting...

   7.  IANA Considerations

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Apr 2014 17:20:00 -0400

Well, I read this draft, but I don't think I understand it.

I may *partially* understand it in the context of IMS. But I don't 
understand it in the abstract.

In particular I don't understand what you mean by "traffic leg". What I 
do understand is that the signaling path of a request can be described 
by a route. When the request is sent the route is described, in part, by 
the Route header and the r-uri. When the request has reached the 
recipient, the route is described by the Via header. But the Route 
header may be incomplete, and the Via header may be obfuscate. But 
certainly the request ends up traversing some set of sip nodes starting 
with the UAC and ending with the UAS, and we can view it as the actual 
route even if it was never encoded anywhere.

I *guess* you are proposing that this route can be *partitioned* into 
segments called "traffic legs", that these legs have differing 
behaviors, and that these behaviors can be enumerated and named. Is that 
right?

Further, I guess you are asserting that it is useful to know which URIs 
of hops along the route are part of which traffic legs.

Then, the description of the parameter says the uri with the parameter 
is the *end* of a traffic leg with that name. It says nothing about 
which node or URI *starts* each leg.

Suppose I have a route from Alice to Bob consisting of:

Alice -> P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> Bob

When I partition this into traffic legs, do the boundaries between the 
partitions fall on the nodes or on the hops between the nodes? In other 
words, does a node that ends one leg also originate another leg? What if 
a request was sent in the opposite direction over the same path. How 
would the use of iotl parameters differ on the two? Apparently you also 
are assuming that the *sender* of a request knows when a URI it is 
adding to the request denotes the end of a traffic leg. (Could it not be 
possible that the sender doesn't know, but the recipient does?)

Another thing: Dale already asked about the IANA considerations - 
whether there are defined values. ISTM that in the context you have in 
mind (IMS) there are a fixed set of values that make sense, and further, 
that only certain combinations of those values make sense. In some other 
application, other values and combinations of values might make sense.

Most of what I mention above seems like stuff that ought to be addressed 
in the draft, one way or another.

It also seems to me that there is some conceptual overlap between this 
draft and what INSIPID is doing. It too is concerned with requests and 
dialogs that traverse multiple legs, and has had difficulty clearly 
defining what it talking about. It is concerned largely with situations 
where the legs are defined by B2BUAs. I don't know if the legs you are 
talking about are the same or not.

If B2BUAs (especially SBCs) are involved, is it important whether the 
iotl parameters are preserved e2e?

	Thanks,
	Paul

On 4/28/14 7:44 AM, Christer Holmberg wrote:
> Hi,
>
> We’ve submitted a new draft, draft-holmberg-dispatch-iotl-00.
>
> The draft defines a new SIP URI parameter, which can be used to
> associate a SIP URI with the end of a so called traffic leg, which is a
> specific part of a signaling path (see more in the draft for details).
> This information is very important in scenarios where the signaling
> traverse different operator networks, where a user can be located in its
> home network or in a visited network (in case of roaming), etc.
>
> The draft is needed for 3GPP, but we’ve tried to write it in a way so
> that it can also be applied to other environments.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Apr 2014 12:41:56 +0000

Hi Paul,

See reply inline.

> I may *partially* understand it in the context of IMS. But I don't understand it in the abstract.
>
> In particular I don't understand what you mean by "traffic leg". What I do understand is that the signaling path 
> of a request can be described by a route. When the request is sent the route is described, in part, by the Route 
> header and the r-uri. When the request has reached the recipient, the route is described by the Via header. But 
> the Route header may be incomplete, and the Via header may be obfuscate. But certainly the request ends up 
> traversing some set of sip nodes starting with the UAC and ending with the UAS, and we can view it as the actual 
> I *guess* you are proposing that this route can be *partitioned* into segments called "traffic legs", that these legs 
> have differing behaviors, and that these behaviors can be enumerated and named. Is that right?

Correct.

> Further, I guess you are asserting that it is useful to know which URIs of hops along the route are part of which traffic legs.

Correct.

> Then, the description of the parameter says the uri with the parameter is the *end* of a traffic leg with that name. It says nothing about which node or URI *starts* each leg.

The each value description, the text says between which 3GPP nodes the traffic leg spans. There is no need to indicate the *start* in the signaling.

If someone wants to use the mechanism in a non-3GPP environment, he/she of course needs to provide similar text for that specific environment.

> When I partition this into traffic legs, do the boundaries between the partitions fall on the nodes or on the hops 
> between the nodes? In other words, does a node that ends one leg also originate another leg? What if a request 
> was sent in the opposite direction over the same path. How would the use of iotl parameters differ on the two? 
> Apparently you also are assuming that the *sender* of a request knows when a URI it is adding to the request 
> denotes the end of a traffic leg. (Could it not be possible that the sender doesn't know, but the recipient does?)

In IMS the sender always knows.

> Another thing: Dale already asked about the IANA considerations - whether there are defined values. ISTM that in the context you have 
> in mind (IMS) there are a fixed set of values that make sense, and further, that only certain combinations of those values make sense. 
> In some other application, other values and combinations of values might make sense.

Sure, and the ABNF does allow for additional values/combinations to be defined - either in the draft itself, or in future (we obviously need to define the procedure for defining new values).

> Most of what I mention above seems like stuff that ought to be addressed in the draft, one way or another.

Sure - this is only the first version :)

> It also seems to me that there is some conceptual overlap between this draft and what INSIPID is doing. It too is concerned 
> with requests and dialogs that traverse multiple legs, and has had difficulty clearly defining what it talking about. It is concerned 
> largely with situations where the legs are defined by B2BUAs. I don't know if the legs you are talking about are the same or not.

There is no relation with the session id.

In addition, with session id the aim is to keep the same value end-to-end, which is not the case with iotl (as there may be multiple traffic legs on the path).

> If B2BUAs (especially SBCs) are involved, is it important whether the iotl parameters are preserved e2e?

The iotl parameter only needs to be preserved until it is "consumed" at the end of the traffic leg.

Regards,

Christer

On 4/28/14 7:44 AM, Christer Holmberg wrote:
> associate a SIP URI with the end of a so called traffic leg, which is 
> a specific part of a signaling path (see more in the draft for details).
> traverse different operator networks, where a user can be located in 
> its home network or in a visited network (in case of roaming), etc.
>
> The draft is needed for 3GPP, but we've tried to write it in a way so

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Apr 2014 13:15:56 -0400

>> Further, I guess you are asserting that it is useful to know which URIs of hops along the route are part of which traffic legs.

Useful to whom? For what? (More on this below.)

> The each value description, the text says between which 3GPP nodes the traffic leg spans. There is no need to indicate the *start* in the signaling.

There is no need because it is implicit? Or because it is not needed for 
the uses you have in mind?

> Sure, and the ABNF does allow for additional values/combinations to be defined - either in the draft itself, or in future (we obviously need to define the procedure for defining new values).

Yes. You probably wouldn't want just anybody defining a new value to be 
used in 3gpp networks. Somebody wanting to use this for some non-3gpp 
purpose would presumably need to define a whole new *set* of values to 
use. That does have implications on how these are defined.

> In addition, with session id the aim is to keep the same value end-to-end, which is not the case with iotl (as there may be multiple traffic legs on the path).

I didn't mean to imply that there is any *direct* connection.
But the notion of partitioning paths into legs shows up in multiple 
cases. I'm watching to see if there is any more general work that is needed.

> The iotl parameter only needs to be preserved until it is "consumed" at the end of the traffic leg.

That seems to open up another discussion. It is a continuation of the 
question I had above who uses the iotl parameter values, and for what.

When you say that the parameter identifies the end of a leg, and is 
consumed at the end of the leg, that implies to me that this serves as a 
request that the node identified by the URI perform some action implied 
by the iotl value.

If that is what this is about, then it should be spelled out clearly.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 30 Apr 2014 15:01:10 -0400

As far as I can tell, the draft refers to "signaling path", but it
does not distinguish whether the signaling path is the routing of a
single dialog, or whether it is broken into multiple dialogs by
B2BUAs.  I don't think this changes the proposal technologically, but
it should probably be stated explicitly somewhere.  It *is* a
requirement of the solution.

It seems that the intention is that at any point, a progressing
dialog-establishing or out-of-dialog request is labeled regarding
which call leg it is within by the iotl parameter of the URI currently
used for routing (the topmost Route or the request URI).  This is a
bit incorrect categorically, because:

1. it's not a property of the destination, its a property of the
   dialog, or part of the dialog

2. overlooking that, it's not really a property of the URI, its a
   modifier of how the URI is *used*

(1) suggests that there should be a separate header to label the
request.  But that might be even more complex to define in order to be
able to have a single dialog contain several call legs.

(2) suggests that the iotl data should not be a URI parameter, but
rather a header parameter.  The Route header has header parameters,
but the request-URI doesn't; I suppose the analogous item is the To
header, which does have header parameters.

Those solutions aren't satisfying, either.

Dale

---

From: Michael Hammer <[email-masked]>
Date: Wed, 30 Apr 2014 20:34:30 +0000

Dale,

I don't think you can say it is part of the dialog, 
since it breaks depending on how middle-boxes manage dialogs.
Could be orthogonal.

I think you are on the right path though.

Since this seems to be all about an attribute of the route, 
why wouldn't the Router header parameter be correct?

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Dale R.
Worley
Sent: Wednesday, April 30, 2014 3:01 PM
To: [email-masked]
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

As far as I can tell, the draft refers to "signaling path", but it does not
distinguish whether the signaling path is the routing of a single dialog, or
whether it is broken into multiple dialogs by B2BUAs.  I don't think this
changes the proposal technologically, but it should probably be stated
explicitly somewhere.  It *is* a requirement of the solution.

It seems that the intention is that at any point, a progressing
dialog-establishing or out-of-dialog request is labeled regarding which call
leg it is within by the iotl parameter of the URI currently used for routing
(the topmost Route or the request URI).  This is a bit incorrect
categorically, because:

(1) suggests that there should be a separate header to label the request.
But that might be even more complex to define in order to be able to have a
single dialog contain several call legs.

(2) suggests that the iotl data should not be a URI parameter, but rather a
header parameter.  The Route header has header parameters, but the
request-URI doesn't; I suppose the analogous item is the To header, which
does have header parameters.

Dale