Re: Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt
Peter McCann <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8__24577.4935502142$1373730628$gmane$org@dfweml512-mbx.china.huawei.com> |
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? 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? -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