Re: [mif] Hybrid Access Problem

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 11 November 2014 09:18 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EE11A888D for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 01:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.094
X-Spam-Level:
X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyGG0kZ33XPR for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 01:18:46 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB5D1A1BDF for <mif@ietf.org>; Tue, 11 Nov 2014 01:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25951; q=dns/txt; s=iport; t=1415697526; x=1416907126; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2ORustIuY90QWwFoN2jXDv/Z3b6GKfaEONtYTiSlE18=; b=Lm/abpLLSgcobo9GiLhs2Al9UPhMrcTKwdji+nCvEzPK4IX0CcIDlGC7 OLJ3qohaJqbBQIpjOcc/yNYvrS0+AwBJMfLO6zgHi8vyL68XozxwhH0vf 3UCM9n1Zgumxll52Dn5kELuqJuE5csM9ak3mGCKxHhecnQ5wTDlKkzcWD Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFACfTYVStJA2G/2dsb2JhbABcgkhGgS0E01ECgR0WAQEBAQF9hAIBAQEDAWcXCwIBCBEDAQIhBwchERQJCAIEARIbiBEDCQnGBA2GUwEBAQEBAQQBAQEBAQEBARqOW4IoFwGESwWSMYlighKBNINPimyGcYN6bIFIgQMBAQE
X-IronPort-AV: E=Sophos; i="5.07,359,1413244800"; d="scan'208,217"; a="95422029"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 11 Nov 2014 09:18:45 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAB9IiJd002879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 09:18:44 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 03:18:44 -0600
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Margaret Wasserman <margaretw42@gmail.com>, "mif@ietf.org List" <mif@ietf.org>
Thread-Topic: [mif] Hybrid Access Problem
Thread-Index: AQHP/ZB9mXHfbIfmP0WSyzs1ET1AQA==
Date: Tue, 11 Nov 2014 09:18:44 +0000
Message-ID: <D087026C.178115%sgundave@cisco.com>
References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <D0765101.175805%sgundave@cisco.com> <005401cff509$3719eb30$a54dc190$@com> <D0869CBD.177FDF%sgundave@cisco.com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com>
In-Reply-To: <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [10.21.114.240]
Content-Type: multipart/alternative; boundary="_000_D087026C178115sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/2sC2OYjEOiwvuHA5z7Lr_bPMubc
Subject: Re: [mif] Hybrid Access Problem
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 09:18:51 -0000

> If you have an ISP today that has two different access networks available, such as one 3GPP network and one DSL network, how do(es) the gateway box(es) (connected to both networks) decide where it should send each packet it receives?  I think there are several possible cases here;

The IP address/prefix that is given to the  PDN connection of the mobile node  is topologically anchored on the PGW  and the IP traffic that is routed on the 3GPP link is ONLY the traffic using the source address/prefixes associated with that PDN connection. All the functions in the 3GPP network including QoS, charging ..etc is only for that IP address/prefix.

For the case where the mobile node is a mobile router, we have specified support for prefix delegation in 3GPP Rel-12, where the mobile router can obtain a set of delegated prefixes for its ingress networks. But even those delegated prefixes and the IP address/prefix on the primary PDN connection MUST be part of a single aggregate block and that aggregate block is again topologically anchored on the PGW. So, the IP traffic that is routed and seen on the 3GPP link is only the traffic associated with that PDN connection.

For all other cases such as where the IP prefixes in the ingress network behind the mobile router not belonging to the 3GPP network,  either those packets must NAT/PAT translated, or carried over an overlay tunnel  (GRE/UDP) path. In the later case the ingress prefixes are hidden from the transport network and so the 3GPP network does not care about those prefixes. It never sees them.

Now, if we map this to NEMO use-case, it is exactly the case of a mobile router connected to two access networks; The ingress prefixes behind the mobile router are prefixes anchored on the mobility anchor (HA/LMA/PGW) and the traffic from the ingress network is tunneled to the anchor. An overlay tunnel path is set up between the MR and the HA and the overlay topology is hidden from the transport network.

Please see inline


Regards
Sri


From: Margaret Wasserman <margaretw42@gmail.com<mailto:margaretw42@gmail.com>>
Date: Monday, November 10, 2014 8:08 PM
To: "mif@ietf.org<mailto:mif@ietf.org> List" <mif@ietf.org<mailto:mif@ietf.org>>
Subject: [mif] Hybrid Access Problem



Let me see if I can start a technical discussion here...

If you have an ISP today that has two different access networks available, such as one 3GPP network and one DSL network, how do(es) the gateway box(es) (connected to both networks) decide where it should send each packet it receives?  I think there are several possible cases here;

[Sri] Not sure, I followed the below conclusions or the assumptions. But, I will try.


(1) There is one gateway attached to both outbound networks.  This has two sub-cases:

[Sri] Ok

(1.1) Hosts behind the single gateway have separate addresses on the two attached networks.  In that case, the gateway is constrained to send packets over the outgoing network that uses the address prefix that matches the source address, or the packets will be thrown away by ingress filters on the other side.  So, the network choice is made by the hosts.

[Sri] Hosts can have addresses belonging to the access network, or they can be from the anchor in the home network. For the later case, there can be an overlay topology. The gateway can potentially tunnel the packet to an anchor (Ex: BNG) and in that case the ingress side network prefixes are hidden from the transport network.


(1.2) Hosts behind the gateway have only one address each.  This has two sub-cases:

[Sri] The gateway can include multiple prefixes in the RA sent on the ingress link and so the hosts CAN have multiple IP addresses/prefixes.


(1.2.1) The gateway has separate addresses on the two networks, and does some sort of translation from internal to external addresses in the prefix of the "right" outgoing link.

[Sri] Translation is one option for the case where the addresses are private address relevant only on that link. Tunneling is another option when the addresses belong to a remote gateway. There is also the third option, where the ingress prefixes are from the access network and there is normal routing.


(1.2.2) The gateway has only one IP address that is somehow shared across the two links.

[Sri] Not sure, how its possible. The IP address given for the LTE connection cannot be the  IP address given on the DSL link. The connection is tied to a IMSI and that cannot be on two different gateways.


(2)  There are two gateways, each attached to a single outbound network.  In this case, hosts will always have separate addresses for the two networks, and will need to make a decision about which outbound network to use.

[Sri] Not sure, how the host with a single interface is attached to two gateways simultaneously ? Is the host again another router ?


Cases 1.1 and 2 are essentially the same from a host standpoint, in that the host needs to make a network choice.  This is a problem we have discussed in MIF -- What sort of information does/should the host need to make that choice, and how is that information communicated to the host?

[Sri] This is nothing to with the host. Its about the addressing and the ownership of the addressing that is enabled on that link. This is a network decision and not  a host decision.


Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for multi-homing.  The IETF generally prefers to avoid recommending solutions that use NAT, but do we have a better answer?

[Sri] NAT is an option, but there are other modes.

  1.  Allocate prefixes from a remote anchor and set up tunneling to that anchor
  2.  Enable routing for the ingress prefixes in the transport network; Make them routable in the transport network (Ex: Rel-12 3GPP PD Work).

Case 1.2.2 becomes a layer 2 problem and is probably outside the scope of the IETF.


Are there cases that I am missing here?

[Sri] Not sure I agree with the conclusions.


Margaret