Subject: [Tsvwg] Comments on draft-tsvwg-mlpp-that-works-02 (Architecture)

From: [email-masked]
Date: Thu, 25 Aug 2005 11:17:10 EDT

While still waiting for the Last Call to be formally announced via e-mail, 
here are some further comments:

This draft concentrates completely on the end-to-end model in which the SIP 
endpoints (UAs) directly send signaling messages between them. This requires 
that every endpoint (UA) supports RSVP, and the example signaling shown 
indicates that a call will fail if one or the other does not support RSVP, even if 
capacity happens to be available at the time.

While some of the introductory text was modified for this new version -02, 
the strong implication remains that the procedures described will meet the US 
DoD requirements. Those requirements have been iterated in the two referenced 
"Assured Service" draft (currently expired).

The referenced "Architecture" draft specifies that the "SIP trapezoid" must 
be used, and that "proxies" must perform some call control functions in order 
to properly provide the Assured Service capabilities, especially preemption. 
One essential function of the proxy is to "hide" information which the other 
user is not allowed to see as required by the referenced "Requirements" draft. 
Other DISA documents are also identifying the requirement for such a network 
entity to take part in every call setup, often called a "softswitch".

It would be useful to have a description of how RSVP and other SIP messaging 
would operate in such an architecture, otherwise it can not be claimed to 
satisfy the DoD requirements.

The issue of which Reason header for preemption to pass is one of the issues 
which the "proxy" or "softswitch" must resolve. In order to provide that "all 
SIP nodes are synchronized to a preemption event" as stated in Section 2.1 of 
this draft, an endpoint performing preemption at the UA or due to RSVP or some 
other reason, must pass that proper reason code to the network node. It must 
also be passed between network nodes, or "proxies". However, since the 
requirement is that the other user does not see the actual reason for preemption, the 
final network node must change it to the "generic" reason before passing it 
to that other user. (This is really no different from the requirements in other 
networks to prevent calling line ID or Call forwarding information from being 
passed to the other user if the first user wants it restricted. These 
functions require the use of  a "proxy" or other network entity to modify the SIP 
messages, and have resulted in significant discussion among IETF participants 
without any apparent resolution.)

Specifically, the operation of RSVP in this draft requires the endpoint to 
take an active role in setting up the reservation, responding correctly to 
errors, as well as responding correctly to RSVP-initiated preemptions. This may 
lead to serious problems such as endpoints that do not respond properly. It would 
also require that absolutely every phone and gateway in the DoD environment 
support RSVP. For these reasons, it was specified that a "network" entity 
(proxy) must take an active part in this process. Consequently, it is necessary for 
the RSVP-detected need to preempt to be passed to the proxy, which then needs 
to decide what to do.

Without a description of how RSVP is used with this required architecture, 
this draft should not claim or imply that it satisfies the DoD requirements.

Another issue of this architecture is the statement in Section 2 that "call 
control is completely divorced from the data plane". While this may be true in 
some SIP network where such "Assured Service" requirements do not exist, the 
functional requirements for the DOD network lead to the Architecture 
requirements (referenced) which require that the call control and data plane not be 
"completely divorced". There must be some connection, in the sense that the call 
control entities ("proxies" or "softswitches") have some way to invoke control 
over the data plane, mostly to authorize new packet flows at a specific 
marking or to revoke such as authorization in case of preemption. While the exact 
nature of this connection is yet to be determined, it is not "completely 
divorced". Otherwise, it would be impossible for CAC (part of call control) to 
determine if there is bandwidth available.

A further unanswered issue about the architecture is indicated by the 
statements about the preemption tone, which presume that every end device (UA) is 
capable of locally generating this tone. Technically, this is the same as what is 
needed to apply Call Waiting tone. It should be noted that, many months ago, 
there was an extensive discussion on the IETF mailing list concerning "Where 
does Call Waiting tone come from" with no apparent resolution or common answer. 
This remains one of the major unresolved issues for VoIP. If the application 
of "MLPP" requires this tone, there needs to be a consistent definition of how 
it is done in a standardized way. If every phone and gateway is required to 
support the full range of tone generation, then so be it, but we have to say 
so. (I notice that the new SIP Forum Phone Task Group does not have this issue 
listed as part of their work.)

Mike Pierce
Artel

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Aug 2005 12:10:31 -0500

Mike

Do you believe that *everything* that is in a SIP message is displayed on a 
UA's display?

DISA has gone to great lengths to have vendors comply with specific 
behaviors of every element in an architecture offering through DISA's 
certification process.

Could one of these requirements *not* be "Do not present to the user a 
unique preemption indication"? Meaning do not display/chime/flash/verbalize 
that there are different instances of preemption, and just give the same 
indication for any form of preemption.

This means the UA has to be well behaved - sure. But if the UA is not well 
behaved, a preemption indication violation of DISA's policy is fairly low 
on the totem pole of what could be bad with a misbehaving UA, I would imagine.

Policy should not be built into the protocol as its normal operation, 
although the "hooks" for enforcement for a customer's policies should be.

This is a hook you do not want turned on at the phone. Vendors are who make 
that configurable. I know we will. If you make this mandatory into your 
network, others will too in order to be considered by DISA.

Does this make sense?

At 11:17 AM 8/25/2005 -0400, [email-masked] wrote:
>This draft concentrates completely on the end-to-end model in which the 
>SIP endpoints (UAs) directly send signaling messages between them. This 
>requires that every endpoint (UA) supports RSVP, and the example signaling 
>shown indicates that a call will fail if one or the other does not support 
>RSVP, even if capacity happens to be available at the time.
>
>the strong implication remains that the procedures described will meet the 
>US DoD requirements. Those requirements have been iterated in the two 
>referenced "Assured Service" draft (currently expired).
>
>The referenced "Architecture" draft specifies that the "SIP trapezoid" 
>must be used, and that "proxies" must perform some call control functions 
>in order to properly provide the Assured Service capabilities, especially 
>preemption. One essential function of the proxy is to "hide" information 
>which the other user is not allowed to see as required by the referenced 
>"Requirements" draft. Other DISA documents are also identifying the 
>requirement for such a network entity to take part in every call setup, 
>often called a "softswitch".
>
>It would be useful to have a description of how RSVP and other SIP 
>messaging would operate in such an architecture, otherwise it can not be 
>claimed to satisfy the DoD requirements.
>
>The issue of which Reason header for preemption to pass is one of the 
>issues which the "proxy" or "softswitch" must resolve. In order to provide 
>that "all SIP nodes are synchronized to a preemption event" as stated in 
>Section 2.1 of this draft, an endpoint performing preemption at the UA or 
>due to RSVP or some other reason, must pass that proper reason code to the 
>network node. It must also be passed between network nodes, or "proxies". 
>However, since the requirement is that the other user does not see the 
>actual reason for preemption, the final network node must change it to the 
>"generic" reason before passing it to that other user. (This is really no 
>different from the requirements in other networks to prevent calling line 
>ID or Call forwarding information from being passed to the other user if 
>the first user wants it restricted. These functions require the use of  a 
>"proxy" or other network entity to modify the SIP messages, and have 
>resulted in significant discussion among IETF participants without any 
>apparent resolution.)
>
>errors, as well as responding correctly to RSVP-initiated preemptions. 
>This may lead to serious problems such as endpoints that do not respond 
>properly. It would also require that absolutely every phone and gateway in 
>the DoD environment support RSVP. For these reasons, it was specified that 
>a "network" entity (proxy) must take an active part in this process. 
>Consequently, it is necessary for the RSVP-detected need to preempt to be 
>passed to the proxy, which then needs to decide what to do.
>
>Another issue of this architecture is the statement in Section 2 that 
>"call control is completely divorced from the data plane". While this may 
>be true in some SIP network where such "Assured Service" requirements do 
>not exist, the functional requirements for the DOD network lead to the 
>Architecture requirements (referenced) which require that the call control 
>and data plane not be "completely divorced". There must be some 
>connection, in the sense that the call control entities ("proxies" or 
>"softswitches") have some way to invoke control over the data plane, 
>mostly to authorize new packet flows at a specific marking or to revoke 
>such as authorization in case of preemption. While the exact nature of 
>this connection is yet to be determined, it is not "completely divorced". 
>Otherwise, it would be impossible for CAC (part of call control) to 
>statements about the preemption tone, which presume that every end device 
>(UA) is capable of locally generating this tone. Technically, this is the 
>same as what is needed to apply Call Waiting tone. It should be noted 
>that, many months ago, there was an extensive discussion on the IETF 
>mailing list concerning "Where does Call Waiting tone come from" with no 
>apparent resolution or common answer. This remains one of the major 
>unresolved issues for VoIP. If the application of "MLPP" requires this 
>tone, there needs to be a consistent definition of how it is done in a 
>standardized way. If every phone and gateway is required to support the 
>full range of tone generation, then so be it, but we have to say so. (I 
>notice that the new SIP Forum Phone Task Group does not have this issue 

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.