Subject: Re: [DNA] Prefix information for link identification in DNA

From: Brett Pentland <[email-masked]>
Date: Mon, 03 Oct 2005 13:05:20 +1000

In the IETF DNA group we have been using the term "link" in the sense
described in RFC 2460 and other IPv6 documents; that is:

    link        - a communication facility or medium over which nodes can
                  communicate at the link layer, i.e., the layer
                  immediately below IPv6.  Examples are Ethernets (simple
                  or bridged); PPP links; X.25, Frame Relay, or ATM
                  networks; and internet (or higher) layer "tunnels",
                  such as tunnels over IPv4 or IPv6 itself.

For DNA we are trying to allow a host to determine whether its existing
network-layer configuration is likely to be still valid or whether it
needs to initiate reconfiguration.  So whether we call it a "link" or
not, the above is the thing we are trying to identify, since it
represents the extent over which the configuration will be valid.

So far we have been using network prefix information for the
identification (not necessarily using a single prefix as a fixed
identifier because the prefixes used can change over time).  What
I am trying to work out is whether there is a good reason why we
need to be able to use non-prefix information to identify this "link".

Any thoughts?
Brett.

[email-masked] wrote:
> Colleagues,
> 
> Please also continue on this discussion of the identification of "link"
> as relevant to the MIH header definition, especially for referring to
> the link in off-link ES/CS references vs. on-link references. Gabriel
> mentioned Ipv6 as a use case to consider for definition of L3 "link",
> and please note IPv6 ND perhaps even more deep use of the concept. Is it
> important that MIH and L3 have interrelated concepts of "link" for any
> reasons (QoS, Application awareness, security, link adaptation, resource
> management, ???)
> 
> The use case of cellular "link" is important, and indicates the
> definition of "link" at L2 needs to be flexible. Describing it in terms
> of MAC service neighbors might be viable within the 802. If the
> definition of L2 link for use in the MIH header is to be media specific,
> then might there be trouble intpreting its meaning/use in a remote MIH
> function? 
> 
> Best Regards,
> Michael
> 
> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Friday, September 30, 2005 8:47 AM
> To: [email-masked]
> Subject: Re: [DNA] Prefix information for link identification in DNA
> 
> Andrea,
> 
> The PoA definition below is going to the direction that the notion of
> PoA is less associated with the notion of "link", as opposed to what you
> made in your previous general statement which I have fully agreed.
> Or you may be introducing a new definition of "link" as "a specific type
> of communication relationship", which seems to be too ambiguous.
> 
> Yoshihiro Ohba
> 
> 
> 
> On Fri, Sep 30, 2005 at 11:25:04AM -0400, Andrea Francini wrote:
>> Trying to finalize one part of the ongoing discussion: the PoA
> definition.
>> I have the impression that some people consider the capability of 
>> supporting MIH as part of the definition of PoA, while other people 
>> don't, giving it only a network connectivity value.
>>
>> What about the following:
>>
>> 1. General definition of PoA:
>>
>> a. "PoA is the first point in the network that acts as the UE 
>> counterpart for a specific type of communication relationship (e.g.,
> L2, L3, MIH)."
>>
>> 2. Accordingly, the following three specific definitions could be
> added:
>> b. "L2 PoA is the network-side endpoint of the L2 link by which the UE
> 
>> connects to the network."
>>
>> c. "L3 PoA is the closest network counterpart for the UE that requires
> 
>> an L3 address to be identified in UE-generated messages."
>>
>> d. "MIH PoA is the closest network counterpart of the UE for MIH
> exchanges."
>>
>> Thanks,
>>
>> Andrea
>>
>>
>> "Stefano M. Faccin" wrote:
>>> Peretz, nobody denies that. The issue here is that what you have
> been saying doe not allow for deployments that do not use any MIH
> services at L2. Even if you may not believe these deployments will
> happen, there are vendors and operators that do believe that their
> networks will only use MIH services at L3, at least for the initial
> deployments. Thjerefore our model and definitions must allow for this.
> In this model, there is no MIH @ L2, and the PoA is in the subnet where
> the UE gets its IP address.
>>> Stefano
>>>
>>> ________________________________
>>>
>>> From: ext Peretz Feder [mailto:[email-masked]]
>>> Sent: Fri 9/30/2005 10:06 AM
>>> To: [email-masked]
>>> Subject: Re: [802.21] [DNA] Prefix information for link 
>>> identification in DNA
>>>
>>> "I do not understand how any one would conclude that the MIH
> services are only between UE and the AP/BS."
>>> The discussion is PoA and not services. The 1st PoA could be L2 for
> IS and CS. With no PoA at L2, the poor UE will have no MIH services
> until IP is established. The performance will be very different, not to
> mention a UE with a bridging only attributes, such as 802.16 terminal
> with only Ethernet CS (no IP CS).
>>> Nobody is saying MIH services are strictly between UE and BS.
> Performance will be better when PoA L2 MIH is established.
>>> Peretz
>>>
>>> On 9/30/2005 10:50 AM, [email-masked] wrote:
>>>
>>>         The MIIS is provisioned between MIH in UE to a network
> counter part any
>>>         where in the network. This network node can either act as a
> proxy info
>>>         server or an info server. We also identified MIIS requires
> L3 and hence
>>>         the WG went through the exercise of identifying all the UL
> requirements
>>>         and establish coordination with IETF. However, in that
> discussion, there
>>>         was no reference to whether the AP/BS was MIH or non-MIH
> capable.
>>>         Even if we leave out the info services from the discussion,
> I do not
>>>         understand how any one would conclude that the MIH services
> are only
>>>         between UE and the AP/BS.
>>>
>>>
>>>
>>>                 -----Original Message-----
>>>                 From: ext Peretz Feder [mailto:[email-masked]]
>>>                 Sent: Friday, September 30, 2005 9:39 AM
>>>                 To: Sreemanthula Srinivas (Nokia-NRC/Dallas)
>>>                 Cc: [email-masked]
>>>                 Subject: Re: [802.21] [DNA] Prefix information for
> link
>>>                 identification in DNA
>>>
>>>                 Are you indicating attaching to a non MIH enabled
> AP/BS and
>>>                 receiving MIH IS over R4 from a remote MIH info
> server?
>>>
>>>                 On 9/30/2005 10:27 AM,
> [email-masked] wrote:
>>>
>>>
>>>                         Did we miss the whole discussion of MIH
> information services?
>>>
>>>                         ________________________________
>>>
>>>                                 From: ext Peretz Feder
> [mailto:[email-masked]]
>>>                                 Sent: Friday, September 30, 2005
> 9:16 AM
>>>                                 To: [email-masked]
>>>                                 Subject: Re: [802.21] [DNA] Prefix 
>>> information for link
>>>
>>>
>>>                 identification
>>>
>>>
>>>                         in DNA
>>>
>>>
>>>                                 "you have first to be very clear
> about what you're attaching"
>>>                                 I would think that in 802.21, we 
>>> first attach the UE's
>>>
>>>
>>>                 MIH to a BS/AP
>>>
>>>
>>>                         that supports MIH capability.
>>>
>>>                                 On 9/30/2005 8:55 AM, Stefano M.
> Faccin wrote:
>>>
>>>                                         Mike, well said!
>>>                                         Stefano
>>>
>>>                                         
>>> ________________________________
>>>
>>>                                         From: ext Mike Moreton
> [mailto:[email-masked]]
>>>                                         Sent: Fri 9/30/2005 3:09 AM
>>>                                         To:
> [email-masked]
>>>                                         Subject: Re: [802.21] [DNA]
> Prefix information for link
>>>                         identification in DNA
>>>
>>>
>>>
>>>                                         To extend (I think!) 
>>> Stefano's point, before
>>>
>>>
>>>                 determining what the PoA
>>>
>>>
>>>                         is, you have first to be very clear about 
>>> what you're
>>>
>>>
>>>                 attaching.  Just
>>>
>>>
>>>                         saying "the terminal" makes no sense,
> because different layers in the
>>>                         terminal's protocol stack attach to
> different places in the network.
>>>                                         For example, the PHY layer 
>>> attaches to the AP,
>>>
>>>
>>>                 but the TCP layer
>>>
>>>
>>>                         attaches to the destination host.
>>>
>>>                                         Mike.
>>>
>>>
>>>
>>>                                                 -----Original
> Message-----
>>>                                                 From: Stefano M.
> Faccin
>>>                         [mailto:[email-masked]]
>>>                                                 Sent: Friday,
> September 30, 2005 1:08 AM
>>>                                                 To:
> [email-masked]
>>>                                                 Subject: Re: 
>>> [802.21] [DNA] Prefix
>>>
>>>
>>>                 information for link
>>>
>>>
>>>                                                 identification in 
>>> DNA
>>>
>>>
>>>                                                 Yoshihiro,
>>>                                                 I'm not sure why 
>>> should restrict the
>>>
>>>
>>>                 term PoA to have only a
>>>
>>>
>>>                                                 L2 meaning as you 
>>> suggest below. I
>>>
>>>
>>>                 think we should
>>>
>>>
>>>                                                 distinguish clearly
> between L2 PoA and L3 PoA.
>>>                         For me, the L3
>>>                                                 PoA is where the
> terminal gets IP conenctivity.
>>>                         E.g. for GPRS
>>>                                                 the L3 PoA is the IP
> 
>>> link on which the
>>>
>>>
>>>                 GGSN is located. In
>>>
>>>
>>>                                                 L2, PoA is the point
> where the access-specific
>>>                         L2 connection
>>>                                                 terminates (e.g. an
> AP in 802.11).
>>>                                                 Stefano

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 04 Oct 2005 01:20:10 +0900

Dear Brett

Thanks for your trouble advancing DNA again.

> Though it was in reference to CPL, Keith Moore raised an issue that is
> relevant to both of the link-identification solution proposals (LinkID
> and CompleteRA).  He thought that it is questionable to assume that:
>
>    1) Every network has a router.
>    2) you can name a network using one of its prefixes.
>
> (I hope that's right Keith - I pulled it out of the minutes)
>
> Both of the proposed solutions use prefix information for link
> identification, though neither relies on using a single prefix as
> the link name for eternity.  Both allow the prefix(es) used to
> change over time and are designed so that hosts can cope with
> those changes.  However both also rely on routers to distribute
> this information to hosts which falls apart if assumption 1)
> above is invalid.
>
> So if a link has no router and no prefixes except the link-local
> prefix (which will be the same for all links) we have a problem.
>
> I'm not sure what we can reasonably do at layer 3 if there is(are)
> no router(s) present on the link to help the hosts identify the
> link.  (Any ideas?)

DNA solution checks for link change to verify whether a host has valid
IP configuration so that the host can have Internet Connectivity
without disruption.

For example, a MIPv6 MN may use DNA procedure to determine that it's
CoA is no longer valid, so that it can quickly get a new CoA and send
a BU accordingly.

If we assume a link which doesn't have neither a router nor a (global)
prefix, I wonder whether a host can have Internet Connectivity in such
a link at all.

In general, for Internet Connectivity, i.e. to be able to send/
receive a packet to/ from off-link node, a hosts needs at least
1) a (partially) reachable default router
2) a valid (global) IP address

* In fact DNA tasks were originally to verify the above two
configurations as in the following first PS draft.

http://www.diffeo.com/drafts/draft-jinchoi-dna-dnav6-prob-00.txt

In a link without a router nor a prefix, I wonder which IP
configuration a host needs to change when it moves to a link. In fact,
in such a environment, it's not even clear to me either what
constitutes a link or DNA is needed at all.

So for the time being, IMHO, we'd better focus on a link with a router
and a prefix. I think that DNA is mostly needed in such a link.

> If there are routers present then I think that prefix information
> should be usable for identification.  If there are no global
> prefixes then maybe the solution can require that routers configure
> a ULA prefix (it might simply be used in an identifier and not
> advertised in a PIO)?

I wonder whether a host can have a global IP address in a link if
there is no global address assigned to the link.

> I guess I would like to find out:
>
> 1. Does anyone think we can come up with a reasonable solution at
>    layer 3 that can deal with links that have no routers?
>
> 1a. Should we?

I don't think we can design a meaningful DNA solution in such a link.

> 2. If we can't/won't, and thus we can make use of routers in
>    identifying other links, can anyone explain why prefix
>    information cannot/must not be used in some way for identifying
>    links?  (Note that using prefix information doesn't require
>    picking a single fixed prefix to act as the identifier)
>
> 2a. If it is *possible* to use prefix information in general to
>     identify links, then is there a good reason why we should
>     design an identification scheme that allows the use of non-
>     prefix information for link identification?

I think that it's ok to use a prefix for link identification.

Thanks in advance for your kind consideration.

Best Regards

JinHyeock