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

Hi, Satoru,

Satoru Matsushima wrote:
> Hi Pete,
> 
> Thanks for your comments.
> 
> On 2013/07/14, at 0:49, Peter McCann <[email protected]> wrote:
> 
>> Hi, Ryuji, Satoru,
>> 
>> If I understand your draft correctly, you are encoding the PGW ID
>> and the TEID into the prefix portion of an IPv6 address.  You seem
>> to allocate
>> 16 bits for the TEID.  I thought that TEIDs in 3GPP were 32 bits.
>> Do you have enough space?  Could you instead encode the TEID in the
>> Interface Identifier part of the IPv6 address?
> 
> Oops. Yes, you are correct. I'll update it soon. Using TEID is one of
> the candidates of generating unique MN's prefix as described in
> stateless-pd draft.
> (http://tools.ietf.org/html/draft-savolainen-stateless-pd-01)
>
> Full of 32bits space is not necessary because embedded ID could be
> shortened by taking a part 16 bits or more longer from an TEID as long
> as its uniqueness is kept. We assume that the RAN side TEID assigned
> by SGW are encoded to MN's prefix.
> 
>> 
>> Perhaps I have misunderstood how the routing update is supposed to
>> work, but why do you need to encode the UE's prefix or address at
>> all in the Next-Hop IPv6 address?  You have the UE's prefix as the
>> Destination, and the Next-Hop can just point to the tunnel, correct?
> 
> UE's prefix is not encoded in the next-hop. The next-hop indicates
> tunnel endpoint in the way of BGP remote next-hop draft. Please see
> "http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-03"

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.

-Pete



> 
> cheers,
> --satoru
> 
>> 
>> -Pete
>> 
>> Ryuji Wakikawa wrote:
>>> Hi
>>> 
>>> We submit a new document.  Your comments are appreciated!
>>> 
>>> thanks,
>>> ryuji
>>> 
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: [email protected]
>>>> Subject: New Version Notification for
>>>> draft-matsushima-stateless-uplane-vepc-00.txt
>>>> Date: July 10, 2013 9:09:44 AM PDT
>>>> To: Ryuji Wakikawa <[email protected]>, Satoru Matsushima
>>>> <[email protected]>
>>>> 
>>>> 
>>>> A new version of I-D,
>>>> draft-matsushima-stateless-uplane-vepc-00.txt
>>>> has been successfully submitted by Satoru Matsushima and posted to
>>>> the IETF repository.
>>>> 
>>>> Filename:	 draft-matsushima-stateless-uplane-vepc Revision: 	 00
>>>> Title:		 Stateless user-plane architecture for virtualized EPC (vEPC)
>>>> Creation date:	 2013-07-10 Group:		 Individual Submission Number of
>>>> pages: 19 URL:             http://www.ietf.org/internet-
>>>> drafts/draft- matsushima-stateless-uplane-vepc-00.txt Status:
>>>> http://datatracker.ietf.org/doc/draft-matsushima- stateless-uplane-
>>>> vepc Htmlized:        http://tools.ietf.org/html/draft-matsushima-
>>>> stateless-uplane-vepc-00
>>>> 
>>>> 
>>>> Abstract:
>>>>  We envision a new mobile architecture for the future Evolved
> Packet
>>>> Core (EPC).  The new architecture is designed to support the
>>>> virtualization scheme called NFV (Network Function Virtualization).
>>>>  In our architecture, the user plane of EPC is decoupled from the
>>>> control-plane and uses routing information to forward packets of
>>>> mobile nodes.  Although the EPC control plane will run on
>>>> hypervisor,  our proposal does not modify the signaling of the EPC
> control plane.
>>>>  The benefits of our architecture are 1) scalability, 2)
> flexibility
>>>> and 3) Manageability.  How to run the EPC control plane on NFV is
>>>> out  of our focus in this document.
>>>> 
>>>> 
>>>> 
>>>> The IETF Secretariat
>>>> 
>>> 
>>> _______________________________________________
>>> dmm mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/dmm
>> 
>> 
>> 
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm