[netext] FW: Needs of traffic spec. on MAG?

"Youn-Hee Han" <yh21.han@gmail.com> Thu, 29 July 2010 13:01 UTC

Return-Path: <yh21.han@gmail.com>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648F228C1E7 for <netext@core3.amsl.com>; Thu, 29 Jul 2010 06:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 FRY51wSgdSzm for <netext@core3.amsl.com>; Thu, 29 Jul 2010 06:01:11 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 0962228C221 for <netext@ietf.org>; Thu, 29 Jul 2010 06:01:11 -0700 (PDT)
Received: by mail-px0-f172.google.com with SMTP id 20so94182pxi.31 for <netext@ietf.org>; Thu, 29 Jul 2010 06:01:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=4j6LDPOS/tCdAiKVcdTSSXfzziJvEj5pwbbol1EK76E=; b=eYFnbzkBlW0sO7yXgyIjCG/al5oLm+tSDDJyulqD7D5N3g4FEgK0O4H4esWmYRA83c bWNw37x7GZ459uexLhVEMlZmd+WxKcZdDk88EwkbJULnebOO3ay1fekYKvD5Z0XHIvm6 kmdov04Y8CpI6skYcKyEuzmoimDOWbieUMZzc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=X6Q27ky+0amMcFhXwPP1oUhc/myowwUGnSuoTCD4ZtqGOfdDYTEeRuo5IoR4XILX4G JcreGjwy0kVgfsdtaL+B2ApDmfZTguoS4Evo+1Wal5+BV3c6VXVHTdxTNdHWQlR/XbAt zFfSqcXPqKnBJKR7uTm/R0ZKtpxaprO/qeeik=
Received: by 10.142.48.18 with SMTP id v18mr63105wfv.101.1280408493678; Thu, 29 Jul 2010 06:01:33 -0700 (PDT)
Received: from pc100 ([220.68.82.28]) by mx.google.com with ESMTPS id 33sm1008705wfg.9.2010.07.29.06.01.31 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 06:01:32 -0700 (PDT)
From: Youn-Hee Han <yh21.han@gmail.com>
To: netext@ietf.org
Date: Thu, 29 Jul 2010 22:01:29 +0900
Message-ID: <4c517bac.21078e0a.0a2b.3776@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acsub/BrXn5EUdMWQ0edv0PIv0g8AwAKhA8gACEG6rA=
Content-Language: ko
Subject: [netext] FW: Needs of traffic spec. on MAG?
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2010 13:01:12 -0000

Hello Carlos,

> > > If finer control is required (e.g., prevent the MN send flows
> > > through a MAG that is not the one the LMA has setup flow mobility
> > > state, or other purposes), then the flow mobility (traffic selector,
> > > e.g., 5-tuple) should be delivered to the MAG.
> >
> > Yes. If we want to support any finer control for flow mobility, IMHO,
> > we need to distinguish downlink flow from uplink flow.
> > Any type of flow, e.g., VoIP flow, has different 5-tuples for downlink
> and uplink.
> 
> different 5-tuple? why? it is just the same, but reversing source and
> destination, right?
> 
> Anyway, 5-tuple is just one way of specifying the flow, more ways can be
> considered, to also support different flow granularities.
> 

According to draft-ietf-mext-binary-ts-04 which is mentioned as one of 
traffic selector in your draft, source IP and destination IP (and source port 
and destination port) are clearly divided in individual fields of option.

Therefore, exactly speaking, the 5-tuple of downlink traffic is different 
from the one of uplink.

Do you mean that when an MAG receives an FMI message including
 one traffic selector (i.e., one 5-tuple), MAG will reverse the source and 
destination IP & Port and store the reversed information to the MAG's traffic 
filter module?

If not so, do you mean that the LMA itself sends the reversed information to MAG?

Otherwise, do you mean that the LMA sends to MAG two traffic selectors, the original 
and reversed ones?

Thanks,

Youn-Hee han