Re: [netext] #7: Logical interface: UL/DL packet processing

<pierrick.seite@orange-ftgroup.com> Wed, 16 March 2011 07:32 UTC

Return-Path: <pierrick.seite@orange-ftgroup.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 C40103A6821 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 00:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 17mC1+zSfI0P for <netext@core3.amsl.com>; Wed, 16 Mar 2011 00:32:54 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 8EB7C3A6820 for <netext@ietf.org>; Wed, 16 Mar 2011 00:32:53 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9E0D56D8010; Wed, 16 Mar 2011 08:34:51 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 903B56C0002; Wed, 16 Mar 2011 08:34:51 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 08:34:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Mar 2011 08:34:18 +0100
Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620190B82F@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A4EB@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] #7: Logical interface: UL/DL packet processing
Thread-Index: AcvZ9zLqaCiqXPtjQvqFSNx7xNb4BQJMWIEwACCXFbA=
References: <066.0751fc96f72ccc7f3cfc7cb7f3fb948e@trac.tools.ietf.org> <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A4EB@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com>
From: pierrick.seite@orange-ftgroup.com
To: telemaco.melia@alcatel-lucent.com, trac+netext@zinfandel.tools.ietf.org, basavaraj.patil@nokia.com
X-OriginalArrivalTime: 16 Mar 2011 07:34:19.0351 (UTC) FILETIME=[8F9D1E70:01CBE3AC]
Cc: netext@ietf.org
Subject: Re: [netext] #7: Logical interface: UL/DL packet processing
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: Wed, 16 Mar 2011 07:32:55 -0000

Hi Tele,

What is the reason for the flow routing policies entry in the LIF table? IMHO, this entry is useless. I mean, routing policies should be node-scoped and only allow to select the interface, i.e configure the flow table; that's it. 

BTW, when a flow handover is performed, policies should also be updated (In order to select the correct interface for new flow). 

BR,
Pierrick

> -----Message d'origine-----
> De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part
> de MELIA, TELEMACO (TELEMACO)
> Envoyé : mardi 15 mars 2011 16:57
> À : netext issue tracker; basavaraj.patil@nokia.com
> Cc : netext@ietf.org
> Objet : Re: [netext] #7: Logical interface: UL/DL packet processing
> 
> Folks, reflecting the discussions in the team here is the proposed text to
> solve this issue. Let us know any problem you see with the proposed text.
> 
> =====
> 6.6. Logical Interface Forwarding Conceptual Data Structures
> 
> 
>    The LIF should maintain the LIF and FLOW table data structures
>    depicted in Figure 4
> 
>      LIF TABLE                           FLOW table
>    +===============================+   +===============================+
>    | PIF_ID | FLOW RoutingPolicies |   | FLOW ID |  PIF_ID             |
>    |        | Home Network Prefix  |   +-------------------------------+
>    |        | Link Layer Address   |   | FLOW_ID |  PIF_ID             |
>    |        | Status               |   +===============================+
>    +-------------------------------|
>    | PIF_ID | FLOW RoutingPolicies |
>    |        | Home Network Prefix  |
>    |        | Link Layer Address   |
>    |        | Status               |
>    +-------------------------------+
>    | ....   | ....                 |
>    +===============================+
> 
> 
>                                  Figure 4
> 
>    The LIF table maintains the mapping between the LIF and each PIF
>    associated to the LIF (see P3).  For each PIF entry the table should
>    store the associated Routing Policies, the Home Network Prefix
>    received during the SLAAC procedure, the configured Link Layer
>    Address (as described above) and the Status of the PIF (e.g. active,
>    not active).
> 
>    The method by which the Routing Policies are configured in the UE is
>    out of scope of this document.  It is however assumed that this
>    method is in place and that these policies are configured in the LIF
>    TABLE.
> 
>    The FLOW table allows a LIF to properly route each IP flow to the
>    right interface (see P7).  The LIF can identify flows arriving on its
>    PIFs and can map them accordingly for transmitting the corresponding
>    packets.  For locally generated traffic (e.g. unidirectional outgoing
>    flows, mobile initiated traffic, etc.), the LIF should perform
>    interface selection based on the Flow Routing Policies.  In case
>    traffic of an existing flow is suddenly received from the network on
>    a different PIF than the one locally stored, the LIF should interpret
>    the event as an explicit flow mobility trigger from the network and
>    it should update the PIF_ID parameter in the FLOW table.  Similarly,
>    locally generated events from the PIFs or configuration updates to
>    the local policy rules can cause updates to the table and hence
>    trigger flow mobility.
> 
> 
> -----Message d'origine-----
> De : netext issue tracker [mailto:trac+netext@zinfandel.tools.ietf.org]
> Envoyé : vendredi 4 mars 2011 00:03
> À : MELIA, TELEMACO (TELEMACO); basavaraj.patil@nokia.com
> Cc : netext@ietf.org
> Objet : [netext] #7: Logical interface: UL/DL packet processing
> 
> #7: Logical interface: UL/DL packet processing
> 
>  Uplink/downlink packet matching: Draft says the Logical interface should
> transmit uplink packets on the same physical interface on which the
> downlink packet was received for the particular prefix/flow. How does the
> logical interface associates an uplink packet to a downlink packet?
> 
> --
> ---------------------------------------+--------------------------------
> ---------------------------------------+----
>  Reporter:  basavaraj.patil@.          |       Owner:  telemaco.melia@.
>      Type:  defect                     |      Status:  new
>  Priority:  major                      |   Milestone:
> Component:  Localized routing          |     Version:
>  Severity:  Active WG Document         |    Keywords:
> ---------------------------------------+--------------------------------
> ---------------------------------------+----
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/7>
> netext <http://tools.ietf.org/netext/>
> 
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext