Re: [Ieprep] Diffserv Code Point for Emergency calls

Fred Baker <fred@cisco.com> Sun, 30 October 2005 19:28 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIqv-000063-Tk; Sun, 30 Oct 2005 14:28:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIqt-00004w-IK for ieprep@megatron.ietf.org; Sun, 30 Oct 2005 14:28:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11682 for <ieprep@ietf.org>; Sun, 30 Oct 2005 14:28:00 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWCfg-0002Ur-PU for ieprep@ietf.org; Sun, 30 Oct 2005 07:52:25 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2005 04:37:49 -0800
X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="358588890:sNHT33216772"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9UCbZJh022797; Sun, 30 Oct 2005 04:37:46 -0800 (PST)
Received: from [10.2.2.142] (sjc-vpn7-25.cisco.com [10.21.144.25]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9UClJ2X014876; Sun, 30 Oct 2005 04:47:19 -0800
In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2801667743@proton.jnpr.net>
References: <9BD5D7887235424FA97DFC223CAE3C2801667743@proton.jnpr.net>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5E7EB875-098D-424A-8287-C7305A482818@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] Diffserv Code Point for Emergency calls
Date: Sun, 30 Oct 2005 07:37:33 -0500
To: Reinaldo Penno <rpenno@juniper.net>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1; q=dns; l=6537; t=1130676440; x=1131108640; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[Ieprep]=20Diffserv=20Code=20Point=20for=20Emergency=20calls| From:Fred=20Baker=20<fred@cisco.com>| Date:Sun,=2030=20Oct=202005=2007=3A37=3A33=20-0500| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Kx2v2r2y8Cch1MjvBmjKydTFh+DuMB+vVko7cNzM7J4srdJgChmFI6fVK39+7ftidLYjMJPV dr4BGvOIEILHSpxdJTyZIT+7OlyMdsqGfMvIziBIDZcahZ5LyrvfTQcoz8UxcO1PZm64zzv/zeX zAAHb0UizmqdrthfqJ6S14Fw=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
Content-Transfer-Encoding: 7bit
Cc: "James M. Polk" <jmpolk@cisco.com>, ken carlberg <carlberg@g11.org.uk>, ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org

On Oct 27, 2005, at 11:29 PM, Reinaldo Penno wrote:

> Hello,
>
> I read draft draft-ietf-tsvwg-mlpp-that-works-02, which I assume it is
> your proposal.
>
> Some questions:
>
> 1. The example is the end if quite complex. I would like to start  
> with a
> bare bores one. Which priority you suggest for everyday 911 calls as
> opposed to normal telephone calls?

mlpp-that-works is not a 911 solution; 911 is about providing a  
service in which an arbitrary user goes to a special peer. MLPP (and  
GETS) are about a special user going to a peer of its choosing and  
getting priority service - and about the peer getting priority  
service while communicating with the MLPP-special user.

> I believe the priorities are below
>
>   The DSN has 5 precedence levels of IEPS in descending order:
>
>         dsn.flash-override
>         dsn.flash
>         dsn.immediate
>         dsn.priority
>         dsn.routine

that is true in the DSN for MLPP service. There are other networks,  
such as GETS which uses the same names but has two levels, the DRSN  
which has six levels, and ADNS which has seven. GSM allows for 15.

> 2. It seems to me your proposal and an emergency DSCP are  
> complementary
> and not mutually exclusive. If signal with RSVP and if you get
> bandwidth, you mark packets with the emergency DSCP.

why?

In the circuit switch network, MLPP/GETS is about getting a circuit.  
There is nothing special about the circuit - it is the same as any  
other circuit. The question is whether you get one or someone else  
does, and MLPP/GETS makes it so that you get one. Ditto ATM - what is  
the marking in the ATM cell for a VC assigned in a priority manner?  
In the PSTN and the ATM networks, this is all in call control. Having  
done it in call control, there is no need to do anything in the data  
plane. Why should IP be different?

And note the security issue with putting it in the data plane. If you  
build a superhighway for script kiddies, they will come. You will  
still have to authenticate and authorize the use of the special DSCP.  
So the DSCP doesn't do away with the need for call signaling seen by  
the network.

You can gratuitously dump mechanisms in to your heart's content. But  
if you don't need them, why? Note RFC 1958 and 3439's comments on  
simplicity and elegance of design. Note RFC 2804's assertion that the  
the random complexity of traditional LI solutions being the best  
reason to not deploy them. I'd really like an answer.

> 3. Not trying to simplify things but premise of this proposal is that
> all IP phones will support RSVP, right?

no. Only the ones you want to provide an emergency service to. But it  
would be simpler and more reliable if they all did.

There are two ways to manage the service at the data layer. You are  
going to have to have an ACL that ensures that only authorized users  
get to use the magic DSCP, or if you simply use EF you will need an  
ACL that ensures that losses, if they come, come from unauthorized  
users.

> 4. Should the phones use RSVP just for emergency calls or for all  
> calls
> in general? I guess they should otherwise the other devices would  
> loose
> track of how much bandwidth has been consumed?

see above.

> Thanks,
>
> Reinaldo
>
>
>
>
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@cisco.com]
>> Sent: Wednesday, October 26, 2005 11:59 AM
>> To: Reinaldo Penno
>> Cc: James M. Polk; ieprep@ietf.org; ken carlberg
>> Subject: Re: [Ieprep] Diffserv Code Point for Emergency calls
>>
>>  From my perspective, the question in the data plane is not whether
>> the packet is part of an emergency session, but whether it is
>> authorized to use the bandwidth. Emergency authorization is a control
>> plane problem.
>>
>> That is why I have suggested authorization of users to use the EF
>> code point during CAC.
>>
>> On Oct 22, 2005, at 8:45 AM, Reinaldo Penno wrote:
>>
>>
>>> Your point is well taken James.
>>>
>>> I guess the risk is no different from what we face nowadays with
>>>
> doom
>
>>> packets marked with EF DSCP. The solution as well is no different
>>>
> from
>
>>> what we have today to deal with those packets. Usually
>>> independently of
>>> the DSCP an endpoint might put in a packet, the edge router perform
>>> classification and if necessary remarks the packet with whatever
>>> DSCP it
>>> should have.
>>>
>>> Therefore, if we just continue with just EF for normal and emergency
>>> voice calls, the risk is the same, the drawback that I see is that
>>>
> we
>
>>> cannot prioritize emergency over normal calls.
>>>
>>> So, in general an edge device that can perform SIP parsing and mark
>>> emergency calls with the emergency DSCP and others with EF DSCP.
>>> Alternatively, in a decomposed gateway scenario the SIP Proxy can
>>>
> let
>
>>> the router know that a certain call is an emergency and that it
>>>
> should
>
>>> be marked differently.
>>>
>>> Regards,
>>>
>>> Reinaldo
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
>>>> Sent: Friday, October 21, 2005 11:02 PM
>>>> To: Reinaldo Penno
>>>> Cc: ken carlberg; ieprep@ietf.org
>>>> Subject: Re: [Ieprep] Diffserv Code Point for Emergency calls
>>>>
>>>> Reinaldo
>>>>
>>>> Adding fuel to a discussion that has churned on many lists over the
>>>>
>>>>
>>> last
>>>
>>>
>>>> several years, I'd really want to understand the threat anaylsis
>>>>
>>>>
>>> observed
>>>
>>>
>>>> by such a proposal (for a emergency DSCP) to ensure it could not be
>>>>
>>>>
>>> used
>>>
>>>
>>>> for a fairly trivial to generate DDOS on the network - even all the
>>>>
>>>>
>>> way to
>>>
>>>
>>>> the PSAP, or just used by neighbors wanting the very best
>>>>
> throughput
>
>>>>
>>>>
>>> for
>>>
>>>
>>>> their game of Doom.
>>>>
>>>> At 10:57 AM 10/21/2005 -0400, ken carlberg wrote:
>>>>
>>>>
>>>>> Hello Reinaldo,
>>>>>
>>>>>
>>>>>
>>>>>> I read
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ieprep-
>>>>> framework-10.txt
>>>>>
>>>>>
>>>>>> and was somewhat puzzled at section 4.1.2. I understand that the
>>>>>>
>>>>>>
>>> IETF
>>>
>>>
>>>>>> wants to be conservative in standardizing new DSCP, but it seems
>>>>>>
> to
>
>>>>>>
>>>>>>
>>> an
>>>
>>>
>>>>>> emergency call DSCP would be accepted by the community (am I
>>>>>>
>>>>>>
>>> wrong?).
>>>
>>>
>>>>>
>>>>> well, from my own take, I would say that the "community" is not
>>>>> against an emergency call DSCP per se, but rather awaits specific
>>>>> proposals with a cautious mindset.  Recall from that section 4.1.2
>>>>> that there is a need to define a behavior in addition to
>>>>>
> identifying
>
>>>>> a code point.  So if you want a code point of 1 or more bits for
>>>>> "emergency", what would be its defined forwarding behavior?
>>>>>
>>>>> one such proposal, primarily aimed at MLPP, is called Multi-Level
>>>>> Expedited Forwarding (MLEF) and can be found at:
>>>>> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-silverman-
>>>>> tsvwg-mlefphb-03.txt
>>>>>
>>>>> I would also suggest reading a counter proposal that avoids
>>>>>
> defining
>
>>>>> a new DSCP:
>>>>>
>>>>>
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-
>
>>>>> mlpp-that-works-02.txt
>>>>> you can dig around the TSVWG archives over the past 2 months for
>>>>> some
>>>>> comments on the draft.
>>>>>
>>>>> -ken
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ieprep mailing list
>>>>> Ieprep@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ieprep
>>>>>
>>>>>
>>>>
>>>>
>>>> cheers,
>>>> James
>>>>
>>>>                                  *******************
>>>>                  Truth is not to be argued... it is to be
>>>>
> presented.
>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ieprep mailing list
>>> Ieprep@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ieprep
>>>
>

--------------------------------------------------------------
"Don't worry about the world coming to an end today. It's already  
tomorrow in Australia." (Charles Schulz )


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep