[PCN] Single DSCP for Admission and Flow Termination Marking

"Jozef Babiarz" <babiarz@nortel.com> Sun, 30 March 2008 19:10 UTC

Return-Path: <pcn-bounces@ietf.org>
X-Original-To: ietfarch-pcn-archive@core3.amsl.com
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F19B3A695F; Sun, 30 Mar 2008 12:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.72
X-Spam-Level:
X-Spam-Status: No, score=-99.72 tagged_above=-999 required=5 tests=[AWL=-1.585, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOYZ+LuCbSq2; Sun, 30 Mar 2008 12:10:30 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699883A6857; Sun, 30 Mar 2008 12:10:21 -0700 (PDT)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043523A6822 for <pcn@core3.amsl.com>; Sun, 30 Mar 2008 12:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifRwBAjkbSVd for <pcn@core3.amsl.com>; Sun, 30 Mar 2008 12:10:13 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8D4573A6907 for <pcn@ietf.org>; Sun, 30 Mar 2008 12:10:12 -0700 (PDT)
Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m2UJ9Ya26101 for <pcn@ietf.org>; Sun, 30 Mar 2008 19:09:35 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 30 Mar 2008 15:10:05 -0400
Message-ID: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Single DSCP for Admission and Flow Termination Marking
Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQ==
From: Jozef Babiarz <babiarz@nortel.com>
To: pcn@ietf.org
Subject: [PCN] Single DSCP for Admission and Flow Termination Marking
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0711107313=="
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org

I was thinking about the encoding and tunneling problem for PCN and I
think there may be a method by which a single DSCP and the ECN field can
be used to signal both admission control and flow termination using ECN
bits. Would like others to think about this and point out any issues
that I may have missed.

The proposed approach can use the EF-admit DSCP for PCN.

My assumptions:
The EF-admit DSCP is used for end-to-end admission control as proposed
by Fred Baker and the PCN wg also reuses this DSCP for PCN based
admission control and flow termination function for edge-to-edge. Should
note that I believe this can also be used for end-to-end PCN based
admission and termination but this is currently out of scope so I will
not discuss.

Proposed encoding:
A packet that is market with EF-admit DSCP means that it is admission
control with that ECN bits be used in the following way:
ECN = 00, means that packet is not-PCN-capable and that admission
control is done some other way.
Interior nodes remark ECN = "01" packets to "11" if traffic rate is
above PCN-lower-rate.
Interior nodes remark ECN = "10" packets to "11" if traffic rate is
above PCN-upper-rate. 

How it works:
For PCN based admission control this approach requires that "probe"
packet be sent at flow setup to determine if a new flow can be admitted.
Example of a probe packet is a RSVP Path message sent from
ingress-edge-node to egress-edge-node. The RSVP Path packet is market
with EF-admit DSCP and has its ECN bits set to "01". Interior nodes
meter EF-admit packets against the PCN-lower-rate and the result of the
meter is passed to the marker where the marker remarks "01" packet to
"11" if PCN-lower-rate was exceeded. The metering and marking behavior
is the so called "threshold marking" as defined in CL or 3sm drafts for
admission control.

For PCN based flow termination, once a flow is admitted,
ingress-edge-node marks admitted PCN traffic with ECN bits to "10".
Interior nodes meter EF-admit packets against PCN-upper-rate and the
results of the meter is passed to the marker where the maker remarks
"10" packets to "11" based on "excess-rate marking" with or without
marking frequency reduction. 

The egress-edge-node knows if the "11" market packet is a probe or it
belongs to an admitted flow therefore it can interpret what the marking
means. 

This sounds simple, so what have I missed? 
This approach works with tunneling, as ECN CE state is copied from outer
to inner IP header on de-encapsulation.
I believe that this marking also satisfies guidelines in RFC4774.
Are there any conditions where this marking approach will not work?

One final note:
If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask
Fred Baker to add a statement in to his draft that the ECN bits in the
IP header are used for other function and that RFC3168 does not apply to
EF-admit DSCP as per guidance in RFC4774.


Regards, Joe
email:babiarz@nortel.com
Telephone:613-763-6098

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn