Subject: Re: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment

From: Christian Vogt <[email-masked]>
Date: Wed, 4 Nov 2009 23:16:41 -0500

Frank and Sri -

I think you should add a motivation for your proposal to the document.
This motivation should answer the questions:  Why does the NAT need to
be de-coupled from the gateway that terminates the existing tunnel?  Why
not co-locate the NAT with the gateway?  This would explain why you want
to extend the existing tunnel towards the NAT using your proposal.

I see one motivation, which applies to networks with multiple gateways:
In those networks, by de-coupling the NAT from the gateways, the global
IPv4 addresses on the external side of the NAT can be shared more
efficiently compared to co-locating a separate NAT with every gateway.

Are there other motivations for your proposal?

- Christian

On Oct 15, 2009, Frank Brockners wrote:

> FYI. We just wanted to draw your attention to a new draft "Gateway
> Initiated Dual-stack lite" - which outlines a modified deployment
> approach of the  original dual-stack lite. The approach applies to  
> those
> network architectures which already employ some form of tunneling
> technology in the access network. The key idea is to leverage the
> existing access tunnel (which means that architectural changes within
> the access network are limited to the gateway terminating access  
> tunnel)
> and stitch it together with a softwire connecting to the CGN. While
> largely targeted at mobility architectures, the solution could be
> applied to broadband environments as well.
>
> A copy of the draft is available at:
> http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00
> .txt
>
>
> We appreciate your thoughts and comments.
>
> Thanks & regards, Sri & Frank

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 04 Nov 2009 21:51:01 -0800

Hi Christian,

Thanks for the review. We can surely add some text on the placement of the
CGN. Based on the topology and network design considerations, operators may
choose to place the CGN in the PDN gateway, or at the edge of the IPv4
network with the fixed and mobile networks within the CGN scope. As you
pointed out, the collocation of the both the functions on the PDN, do
require management of the shared address space. However, the spec does not
mandate the placement of the CGN function, as that is a typical deployment
and network topology consideration and its up to the operator. We can surely
add some text on this aspect.

Regards
Sri

---

From: Christian Vogt <[email-masked]>
Date: Thu, 5 Nov 2009 01:49:09 -0500

Sri -

To clarify:  In addition to saying that an operator COULD decouple the
NAT from the gateway, it would be good to identify the scenarios where
the NAT MUST be decoupled from the gateway.  It is these and only these
scenarios that motivate your proposal.

But then again, there is at least one motivating scenario:  higher
efficiency of IPv4 address sharing in networks with multiple gateways.

- Christian

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 04 Nov 2009 23:12:26 -0800

Hi Christian,

> efficiency of IPv4 address sharing in networks with multiple gateways.

Sure, we can certainly add the motivation for that configuration. It is to
be noted that the spec is also supporting the allocation of the same IP
address for all UE's. Its solving this in a consistent way for all mobility
architectures (MIPv6, GTP & PMIPv6), by applying dual-stack lite approach in
the gateway initiated mode. Now, if the GGSN and CGN are collocated in a
given scenario, still there is some context sharing between those two
elements that allows the GGSN to route the packet to the UE correctly, it
may be internal to a given implementation. The resulting side-affect of this
is a simple migration approach, with minimal changes to the PDN.

- Solves the IPv4 exhaust issue
- UE can be a legacy IPv4-only node or a dual-stack node
- There is no need for IPv6-only bearer, or IPv6-only transport for UE
- CGN and PDN can be collocated or decoupled. When they are decoupled,
allows the network to be IPv4 or IPv6
- There is no change to the EPC, or to the address assignment procedures
- No changes to the UE architecture

This in essence provides a IPv6 migration approach for mobile operators and
the solution is valid for other architectures as well.

Sri