Re: Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt

Hi Pete,


On Thu, Jul 18, 2013 at 2:11 AM, Peter McCann <[email protected]>wrote:

> Hi, Satoru,
>
> Satoru Matsushima wrote:
> > On Wed, Jul 17, 2013 at 12:10 AM, Bruno Mongazon-Cazavet
> > <[email protected]> wrote:
> >
> >
> >       Le 16/07/2013 16:27, Peter McCann a écrit :
> >
> >
> >               Satoru Matsushima wrote:
> >
> >
> >                       Hi Peter,
> >
> >                       On 2013/07/16, at 3:49, Peter McCann <
> [email protected]> wrote:
> >
> >
> >                               I guess I don't understand the "PDN
> Prefix" and "subnet ID" fields
> >                               that you have in Figure 4.  You state:
> >
> >                                  Each PDN is assumed to have single or
> several prefixes (called
> > PDN                              prefix) used to generate UE's address.
> Followed by the PDN
> > prefix in                                Figure 4, there is 16-bit TEID
> assigned for a UE's
> > session at SGW on                                the control plane.
>  TEID is 16 bits identifier
> > in GTP header to                                 distinguish each
> bearer.  The remaining bits are
> > filled by subnet ID.                             The prefix is allocated
> per UE and used for
> > address assignment by                                    SLAAC or
> DHCPv6.                             Is Figure 4 supposed
> > to be the Next Hop or the Destination?  I assumed
>       it was Next Hop
> > because it has the TEID encoded in it.  However, some
>               of the above
> > paragraph leads me to believe it is about the UE's user
>               plane IP
> > address.
> >
> >
> >
> >                       The figure 4 illustrates UE's prefix so it shows
> the destination.
> >                       Encoding TEID is just a seed to create UE's prefix
> in the
> > stateless-pd                  manner.
> >
> >
> >               Doesn't the TEID change on every eNB handover?  I thought
> the UE's
> > prefix                should remain constant across handovers.
> >
> >
> >
> >
> > If you use stateless-pd rule for UE's prefix generation, the embedded
> > TEID is SGW assigned one. So the delegated prefix is stable during
> > across eNB handover. Please see the section 3.3 in update version of
> > the draft. Anycast routing no longer requires hand-over between SGW in
> > virtualized EPC.
> >
> >
> >
> >       Yes TEID changes on handover and when UE exits Idle-Mode (it has
> > previously entered).
> >
> >
> > Thanks, we haven't mention about in the case of Idle-Mode exit. will
> > update with it in a next version. It would be in control-plane
> > awareness section.
>
> I think taken together, these facts would mean that the TEID space is
> shared across all EPC-E devices (they all have the same anycast address)
> and also that a TEID would need to remain allocated even to idle UEs.
>
> Would you eventually run out of TEID space?
>

To be honest, I'm not sure whether the 32bits space of TEID could be
exhausted in almost deployment cases. :)
But when any logical(TEID, etc.,) or physical(bandwidth, etc.,) resources
are exhausted, you can build additional set of EPC-Es which share another
anycast address. Please see section 4 of the draft.



>
> >                       We hasn't illustrate yet how to encode the TEID in
> next-hop.                    But
> > as we mentioned in the document, we expect BGP remote next-hop as
>               the
> > way to encode it in the sub-TLV of the remote next-hop attribute.
> >
> >
> >               I would think that the Next-Hop would change on mobility
> events, but
> > the           Destination would remain the same (UE prefix).  Why is
> this not
> > the case?
> >
> >
> >
> > Yes, exactly.
>
> Ok, so the Destination IPv6 address needs to remain the same during the
> lifetime
> of a UE session, even across idle transitions and mobility events, right?
>

Right.

regards,
--satoru

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm