HI Sri,
On Mon, Feb 5, 2018 at 10:25 PM, Sri Gundavelli (sgundave) <
[email protected]> wrote:
> Tom:
>
> Thanks! That sounds like some interesting trick. But, let me make sure I
> understood this correctly. So, the
>
identifier space for the MN is encoded in the upper 64-bits. Now, the UE
> can use those bits to generate any Identifier from that space, and use it
> with the SIR prefix to form the 128 bit address. Bear with me, let me use
> an example
>
> MN1 is assigned a prefix *2001:ABCD:CAFÉ*: / 48
> MN2 is assigned a prefix *2001:ABCD:FOOD*: /48
>
> The SIR Prefix for that ILA domain is 2001:DB8::/64
>
> So, the SIR Addresses can be formed using the 16-bit identifier space
> left from the /48 prefix assignment? UE can form any identifier from bit
> space?
>
> No, we want allow a full /64 assignment since that is being already
deployed.
> I can’t figure out the scheme from this below text in 6.3.2. I think I am
> missing the context here. May be you guys discussed this before.
>
>
----
>
> To support /64 prefix assignment with ILA, the ILA identifier can be
> encoded in the the upper sixty-four bits of an address and the lower
>
> sixty-four bits are ignored by ILA. Since only a subset of bits are
> available, a level of indirection can be used so that ILA transforms
> the upper sixty four bits to contain both a locator and an index into
> a locator (ILA-N) specific table. The entry in the table provides the
> original sixty-four bit prefix so that ILA to SIR address
> transformation can be done.
>
> -----
>
>
The SIR prefix and identifier are encoded in the upper 64 bits. Assuming
the network has a /24, and address for /64 assignment might have this
format.
Network SIR/identifier IID
24 bits 40 bits 64 bits
------------------------|------------------------------|--------------------------------------------------|
The IID part is arbitrarily assigned by the device, so that is ignored by
ILA. All routing, lookups, and transformations (excepting checksum neutral
mapping) are based in upper sixty-four bits.
For SIR->ILA transformation, a lookup is done on the upper sixty four
bits. That returns a locator that would have format something like:
Network Locator Locator_index
24 bits 20 bits 20 bits
------------------------|-----------------------|--------------------------|
The packet is forwarded and routed to the ILA addressed by locator (/44
route). ILA, the locator index is used as a key to an ILA-N specific table
that returns the 40 bit SIR/identifier. This value is then written in the
packet do ILA->SIR transformation thereby restoring the original address.
The locator index is not globally unique, it is specific to each ILA-N.
When a node attaches to an ILA-N, an index is chosen so that the table is
populated at the ILA-N and the ILA mapping includes the locator and index.
When a node detaches from on ILA, it's entry in the table is removed and
the index can be reused after a holddown period to purge stale mappings.
Tom
> From: Tom Herbert <[email protected]>
> Date: Monday, February 5, 2018 at 9:13 PM
> To: Sri Gundavelli <[email protected]>
> Cc: Lorenzo Colitti <[email protected]>, "[email protected]" <[email protected]>,
> dmm <[email protected]>
> Subject: Re: [DMM] Fwd: New Version Notification for
> draft-herbert-ila-mobile-00.txt
>
>
>
> On Mon, Feb 5, 2018 at 9:07 PM, Sri Gundavelli (sgundave) <
> [email protected]> wrote:
>
>> > best practice is not to use singleton addresses, but always to provide
>> a /64 prefix.
>>
>> But, how does that work with ILA's approach of identifier management?
>> With the previously IETF recommended approaches in RFC5213 and even in 3GPP
>> architecture, per RFC3315, the network assigned a set of unique prefixes
>> for each MN, allowed the MN to generate the identifiers. Even CGA
>> addressing worked with the per-MN prefix model.
>>
>> But, with ILA there is no concept of prefix assignment. Will ILA network
>> now generate a identifier block for each MN? Is DHCPv6 the only approach?
>>
>> Sri, see section 6.3.2. That describes encoding the identifier in the
> upper sixty-four bits and using an indirection table to accommodate network
> prefixes.
>
> Tom
>
> If that block is not summarizable, will it not result in mapping table
>> size getting multiple many times?
>>
>>
>> Sri
>>
>>
>>
>>
>>
>> From: dmm <[email protected]> on behalf of Lorenzo Colitti <
>> [email protected]>
>> Date: Monday, February 5, 2018 at 8:52 PM
>> To: Tom Herbert <[email protected]>
>> Cc: "[email protected]" <[email protected]>, dmm <[email protected]>
>> Subject: Re: [DMM] Fwd: New Version Notification for
>> draft-herbert-ila-mobile-00.txt
>>
>> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <[email protected]> wrote:
>>
>>> We like like to request that the dmm WG consider ILA as a candidate
>>> protocol for the 3GPP "Study on User Plane Protocol in 5GC".
>>>
>>
>> Echoing Tom's earlier comment about this: I think the address assignment
>> sections (6.3 and 8.3) should be reworded to clarify that for general
>> purpose hosts, best practice is not to use singleton addresses, but always
>> to provide a /64 prefix.
>>
>
>
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
