Subject: [Sip] Manyfolks: Unified local/remote model

From: "Alan O'Neill" <[email-masked]>
Date: Sat, 23 Mar 2002 19:09:31 -0500

Dave,

Here is one way to view local/remote and e2e which I believe better supports
inter-domain preconditions. This is through the removal of the two distinct
status types because they are a barrier to efficient offer/answer
negotiation between heterogeneous domains, specifically because you need to
use a new offer if a UA starts with the wrong status type. It also requires
two sets of processing rules which is unnecessarily complex and avoids the
e2e v segmented beauty contest..It certainly is not a design though just a
way to represent the ideas. 

As before, all preconditions should be assumed to be a request for end to
end resources in the direction indicated by the direction tag. As before all
preconditions requests are e2e in nature but the QoS mechanisms supporting
these may not be. The current status reflects where we are compared to the
desired status. Offerer offers, the answerer answers, and Update is used
where necessary for confirmation. Precondition directions as always are wrt
to the SDP sender

But lets instead use nill, local, remote and localremote where localremote
implies the availability of an end to end QoS protocol. From the view of two
UAs, localremote is as much as we can negotiate as neither UA knows anything
about the core in reality, even with an end to end protocol.

The offerer follows manyfolks-05 and selects between nill, local, remote,
localremote as to its desired status towards meeting preconditions in the
specific direction.  The answerer can then select from the offered desired
status and can specifically choose a subset or move from segmented to e2e
models. This is achieved by both the desired status and strength being
negotiable with the answerer responding to the offerer.

Lets assume for direction caller(offerer) to callee(answerer) we have an
optional precondition.

caller sends a=des:qos optional X send
callee sends a=des:qos optional Y recv

Note that both ends keep there own view of what they have to do to meet
precondition so offerer/answerer des lines are different in each direction.
For below note RSVP is used as one example of a protocol giving feedback)..

Actual		Actual		
Offered X		Answered Y		Meaning
nill			nill			Nothing will be booked
			local			Answerer happy to book its
end
			remote		Answerer books other end using RSVP
but local RSVP not supported.
			localremote		eg e2e via e2e signalling eg
RSVP attempted by answerer for both ends
local			nill			Answerer won't book
anything, offerer can
			local			e2e via segmented model
			remote		Answerer will book resources using
say RSVP
			localremote		e2e via e2e signalling eg
RSVP attempted by answerer for both ends
remote		nill			Anwerer won't book anything,left to
offerer
			local			Answerer happy to book its
end
			remote		Inverse segmented - each doing other
ends QoS (maybe for policy reasons ?)
			localremote		e2e via e2e signalling eg
RSVP attempted by answerer for both ends
localremote		nill			Happy for offerer to do e2e
via e2e signaling
			local			Switch to segmented model
with each doing local
			remote		switch to inverse segmented model
(each doing the others end)
			localremote		answerer over-rules and
wishes to book

Of course the answerer can also respond with 'none' strength to cancel the
offered precondition, or stengthen it to 'mandatory' to tighten the
requirement for the desired status for the offerer. The offerers SDP should
now reflect the change requested by the answerer and no additional desired
status negotiation is possible through updates, which only affect current
status (I think that is optimal)

Now at this point both ends know what needs to be done, and by whom..If
offerer is not happy it can re-offer or end the call-leg. Otherwise we move
to the current-status aspects...

The current-status of the offerer will limit the flexibility open to the
answerer, in its response to the offered desired status, by including
information indicating that the offerer is starting the booking of, or
announcing the availability of, resources matching the offerers desired
status. The answerer should not modify the desired status by contravening
the current status of the offerer.

The current status and each end then moves towards the desired status. The
callee should not alert until the preconditions are met and the caller
should send an Update when it learns additional information not known to the
callee about the current status via changes in its local booking and its
booking of remote resources, whether as part of a segmented, inverse
segmented or end to end signalling model.

I hope I having missed anything and that the addition of an integrated
local, remote, localremote model eliminates two competing approaches and the
risk of the offerer starting with the wrong model. I hope I haven't missed
anything but this is kin of where I was going with my analysis...

Alan.

----------------------------------------------------------------
Notice Regarding Intellectual Property Rights

Flarion's submissions will conform with RFC 2026.  Flarion may seek patent
protection on some or all of the technical information submitted by its
employees in connection with the IETF's standards process.  If part(s) of a
submission by Flarion is (are) included in a standard and Flarion owns
patent(s) and/or pending patent application(s) that are essential to
implementation of such included part(s) in said standard, Flarion is
prepared to grant a license on fair, reasonable, reciprocal (license back)
and non-discriminatory terms on such included part(s).

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 25 Mar 2002 20:01:55 +0200

Hello,

The problem with your suggestion is that the offerer specifies what he
will do, not what he wants. For instance, if the offerer says "remote",
it means (in your model) that he will perform resource reservations in
the answerer's access network. But what we really want to say is: I want
QoS in your access network. Do whatever to ensure that.

You claim that in manyfolks-05 the offerer chooses the status type
(segmented or e2e) and that the answerer cannot change it. This is not a
problem. If I ask for mandatory e2e, I do not want the answerer to
change it to segmented. However, if I ask for segmented and I support
e2e, it will be acceptable for me that the status type is changed from
segmented to e2e. Manyfolks-05 already covers this, since the offerer
will include mandatory local/remote and optional e2e (to indicate
support for the e2e status type). The answerer can upgrade the e2e line
to mandatory, and assume that the local/remote preconditions are met
once the e2e preconditions are met.

Alan, the current manyfolks mechanism is what DCS and 3GPP want.
Everything they need in their call flows is covered by manyfolks-05.
Which is the scenario you have in mind that we do not currently cover?

Thanks,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]