Re: [mif] Hybrid Access Problem

[<[e-mail]>]

Hi,

>-----Message d'origine-----
>De : mif [mailto:[e-mail]] De la part de Behcet Sarikaya
>Envoyé : mercredi 12 novembre 2014 00:32
>À : Margaret Wasserman
>Cc : [e-mail] List
>Objet : Re: [mif] Hybrid Access Problem
>
>On Mon, Nov 10, 2014 at 10:08 PM, Margaret Wasserman
><[e-mail]> wrote:
>>
>>
>> Let me see if I can start a technical discussion here...
>>
>> If you have an ISP today 

"today" is the keyword here. I'll try to clarify what we can do, today, to meet the BBF requirement on "hybrid access"

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;
>>
>> (1) There is one gateway 

Ok, let's talk about CPE here to avoid confusion with a traffic anchoring gateway (e.g. P-GW, Broadband Network Gateway (BNG), or even, "aggregation gateway", which is sometimes used in some hybrid access architecture)

attached to both outbound networks.  This has
>> two
>> sub-cases:
>>
>> (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.
>>
>
>This case is not valid because both attached networks belong to the same
>operator. Also the hosts do not get separate addresses from the attached
>networks, I think.
>

Actually, this is a valid use-case. The point is not to know if access networks are operated but how the addresses, on the egress interface of the CPE, are allocated. Sri has well explained this on a previous email. Taking the example of 4G cellular and DSL egress interfaces, the CPE obtains addresses/prefix on both the cellular and the DSL accesses, respectively topically anchored at the PGW and the BNG. Then these prefixes are delegated to the host, possibly with prefix coloring information.
Then, the host can select the source IP address according the network selected (e.g depending on the application, the host may select a specific egress interface). This behavior should rely on advanced source address selection mechanisms, that are not available today (AFAIK). So, today, most hybrid access implementations are going for the approach described in 1.2.1 case.

>> (1.2) Hosts behind the gateway have only one address each.  This has
>> two
>> sub-cases:
>>
>> (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.
>>
>

Exactly, this is what we have today with IPv4; NPTv6 would allow same behavior on IPv6 network

>Yes, I think this is the case.
>
>> (1.2.2) The gateway has only one IP address that is somehow shared
>> across the two links.
>>

Exactly. This scenario has been discussed in 3GPP, relying on PMIP (RFC5213) to share a same IP address, or prefix, across more the egress interfaces of the CPE.

>> (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.
>>

This is a valid use-case, but it does not meet the BBF requirement. Only CPE with more than one outbound interfaces (e.g. LTE, DSL) is in the scope of the BBF liaison, i.e. only case 1).

>> Cases 1.1 and 2 are essentially the same from a host standpoint, in
>> that the host needs to make a network choice.  

Exactly. Basically we have two scenarios regarding traffic steering decision: it is either the host or the CPE which makes the decision to forward the traffic on the most appropriate egress interface. Today, BBF puts the decision making process on the CPE.

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?
>>
>> 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?
>>
>

This is what it is implemented with IPv4, and, today, we do not have better answer for IPv6.

>This could be the case.
>
>I want to also say here that CPE here is not a mobile router.
>There might be mobile routers that are connected to two networks but not in
>this case, I think.
>

I'm not sure to understand this. Multihomed CPE is a router with more than one egress interfaces and the problem is to distribute the traffic over these interfaces; this is one of the scenarios that NEMO protocol can address...

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

Actually, case 1.2.2 is not necessarily a L2 problem, this is typically a PMIP uses-case where a host (here a CPE) obtains the same IP address/prefix while connecting to different access networks

Pierrick

>> Are there cases that I am missing here?
>>
>> Margaret
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> mif mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mif
>>
>
>_______________________________________________
>mif mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mif

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.