Last Modified: 2004-02-20
For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid.
In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection.
The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached.
In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing.
The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today.
The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions.
The working group will describe best current practice for nodes making use of existing information for detecting network attachment.
The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today.
Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies.
The DNA WG will not define new procedures or APIs related to link layers.
* Define goals for detecting network attachment in IPv6 (Informational).
* Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP).
* Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track).
* Document existing link layer (L2) information which is useful to start detecting network attachment (Informational).
|Aug 04||Submit to IESG Goals for Detecting Network Attachment in IPv6|
|Aug 04||Submit to IESG Recommendations for Detecting Network Attachment in IPv6|
|Aug 04||Submit to IESG Existing Link Layer Hints Catalogue|
|Dec 04||Submit to IESG Protocol Enhancements for Detecting Network Attachment in IPv6|
|Feb 05||Close or Re-charter WG.|
WG.Detecting Network Attachment WG (dna) Tuesday, March 2 at 1300-1400 ============================= CHAIRS: Greg Daley (email@example.com) Pekka Nikander (firstname.lastname@example.org) Notes taken by Carl Williams (email@example.com) Pekka and Greg: DNA meeting is 1st meeting as an official working group. There is a goals draft and it is recommended that you go through that draft. There will be 2 presentations on link layer issues : how to detect layer 3 configuration and layer 3 things. Only clarifying questions during the presentations. What to do with BCP draft status will be discussed at the DNA working group meeting. Working group status on the following items: DNA Goals. Link hints catalog which Alper Yegin is in charge of. Link layer catalog is what existing in current wireless technologies and what is already available in link layer technologies : both wireless and wirelan. BCP editor is Brett Pentland. DAD optimization has moved to IPv6 working group. Have that working group look at those ideas. We will track that work to make sure that these ideas are getting the right amount of attention. Please contact IPv6 working group chairs if you are interested in helping out in this area. The co-chairs expressed an interest in security area reviews of documents produced in DNA as well as cross area review for operation we define as well. We are interested in making sure that the procedures we make are actually useful. There is a quality plan producing work in DNA - tools and mechanisms. Ideally what we would like to see is through internal review of documents before they are advanced. Information on review will be put on the mailing so that feedback can be obtained. Issue tracking will be used. Editors will be the first point of contact that will need to respond to reviews. Chairs will also help out here. Looking for generating standard track documents in this group. Working group documents will all have issue tracking so that everyone knows what is going on. There are tools out there to help us. DNA working group has put in place three processes: 1) input from ADs - takes place once draft is stable; 2) input from other working groups and other areas; 3) once this happens the draft will be released to initial working group last call on the respective document. Glenn Zorn: With regards to the issue tracking system you plan to use, will this be a tool for chairs or an automatic stopper for the draft. Way used in EAP and AAA working groups - has been less than useful because issues are added to the list without any rational or appropriate critic. If someone says there is a problem than it is a problem. Glenn says that the chairs should decide if indeed the submitted issue is a problem. Pekka: Issue tracker is mostly a tool for the editors but also chairs can use it. The issue tracking system has three different purposes: First, keep track of issues so don't get dropped. Second, if have controversial issues that we eventually have a consensus on those; and third: if we get back to some issue that we resolved already we must have some real new input on issue before we resolve it again. We don't want to get into loop of keep going back. That doesn't mean that we can't go back to issues that we resolved. We don't need to resolve it again - we just need a good reason for doing so - for example, new experience, etc. Greg: Some ways issue tracker been used successfully. For example, Jari's usage with the MIPv6 specification - there is an audit trail. Finished this issue and people agreed to this on the mailing list. Issue was tracked from start to finish. Pekka: Chairs need to work with editors and follow the mailing list. Get the issues resolved fairly soon - so issues don't stay there forever. Greg: Moving on to the agenda. There are a couple candidate drafts to consider for working group adoption: Hints and goals. Good work gone into them. These are individual submissions. Review of these documents will be done on mailing list. JinHyeock Choi presented on DNAv6 goals. Definition DNAv6 Goals is a charter milestone. - presentation of progress and review feedback. - existing work is in the draft: draft-jinchoi-dna-goals-00.txt JinHyeock went over 12 goals that are outlined in his draft. JinHyeock then went over problems/issues that were identified: - Should DNA solution take into consideration the problems caused by renumbering. JinHyeock says: No. We don't think that renumbering has anything to do with link change. Comments/issues: Pekka: Renumber was raised on mailing list. Charter doesn't say anything on renumbering. Pekka stated that he and a few other members discussed this issue and concluded that the DNA nodes won't care about renumbering. That you will know in advance of renumbering. Our view is that it may not be a real problem for DNA but we could be wrong. Does anyone feel strongly about renumbering in this work? Erik Nordmark: What does renumbering mean in this context? New prefixed being introduced and old prefixes retired. Is this a problem? Pekka: It may be a problem if you do it quickly. JinHyeock: Little connection to network change. Erik: May be a problem if get a new prefix and you may think you are on a new link. May be fooled that you moved but you didn't. I don't think that this is harmful; you may have wasted a few packets trying to determine your new router for example. Pekka: If you make an assumption that you are coming back to the same link after a very short delay you can rely on the same topology you had before - that is one goal. When we go into the solution space there may be a solution to suggest things like that. If the link goes through renumbering in these kind of scenarios - there may be some problems. Erik: As long as you keep the lifetime in cache then you are fine. You don't do anything different if you stayed on the link. Bechet Sarikaya: These goals look like requirements. Why are they called goals? Pekka: First for practical reasons. Bad reputation of the "R" word in IETF (requirements). Second, if we look at these goals and for example, we want to do something fast and something precise, than these may be conflicting goals. If we make these requirements, we may not be able to fulfill that. So these are the goals that we should work towards. There will be some compromise in the process. Pekka: Please review goals draft and send emails with comments to the mailing list. Now we will spend time on issues that interface with layer 2. We definitely want to have comments/feedback on these drafts as well. L2 hints draft Alper Yegin - Definition of Existing L2 Hints applicable for DNA processes is a charter milestone. - Presentation of progress. - Existing work is in the draft: draft-yegin-dna-l2-hints-01.txt Presentation is recap of what Alper presented at last IETF. Just provide recap. One of the main objectives of this DNA working group is how identify how link layer can help DNA algorithms. The purpose of this draft is to cataloguing well-known link layer technologies and their capabilities - nothing fancy - not purposing how link layers should be verified, etc. Draft defined event notifications from link layer as triggers - and they are triggers to the DNA algorithms. DNA would be a consumer of such triggers. There are two types of triggers discussed in the draft: link up and link down. For example, in cdma2000 PPP establishment would be a link up trigger. Hesham Soliman: Might need to distinguish between linkup first time and link change during handover. Implementation: don't get same trigger - in WLAN for example. Alper: Look at from perspective as two primitive triggers. Pekka: Bring up this discussion after all presentations. Continue on with presentation: Alper states that the draft also defines a hint. A hint from a DNA perspective is auxiliary data delivered in association with a trigger. It has been identified that receiving explicit triggers and hints from the link-layer would expedite the detection process. For example, the link-layer indicating that the host has established a new connection can be used as a trigger to further probe the network for a possible configuration change. Unlike the technologies used in 3GPP/3GPP2, network layer configuration is not provided as part of link-layer establishment in IEEE 802.11 networks. Aside from not providing the IP address configuration, this link-layer does not present a useful hint to be used with the network attachment detection process either. This is due to lack of a one-to-one mapping between IP subnets and link-layer parameters. IEEE 802.21 work on triggers Dj Johnson - Link Layer information where available can provide hints as to handover. IEEE handoff group aims to provide useful information to L2 peers and upper layer protocols. - Discussion of potential interaction or delineation of work between DNA or IETF and 802.21. Reason here: what this IEEE working is doing and how he feels it is relevant to DNA. The documents relevant to the IEEE 802.21 triggers discussion this afternoon can be found at: http://www.ieee802.org/handoff/march04_m eeting_docs/Generalized_triggers-02.pdf http://www.ieee802.org/handoff/march04_m eeting_docs/802.21_IETF_DNA_r2.pdf http://www.ieee802.org/handoff/march04_m eeting_docs/802.21_IETF_Mobopts_r1.pdf 802.21 IEEE group has been approved as a full IEEE WG since February 27. Some areas that the 802.21 group is looking at: (1) Multi-interfaced devices (2) Session maintence across heterogenous media and (3) L2 support for L3 DNA and L3 mobility optimizations. David stated that some of the problems that they intend to address deal with issues such as that you don't know what you are to you are associated or plugged into a L2 network. Upper layers don't know what is going on at L2 and so can't make good handover decisions. There is no media independent way for asking for handover related information over a link. A conduit is needed. David presented that some of 802.21 working group priority work is related to DNA - put in place useful L2 network detection methods. Also to do handover optimization - handover information and transport as well as L2 triggers. Other things such as Cellular coupling methods are part of the problem scope as well. DNA related work includes CUPE (Controlled/Uncontrolled Port Entity) which provides media independent access to information. DNA is the primary purpose of that information. David will talk about Triggers in MOBOPTS. David stated that high order bit of his coming to IETF is to advance coordination of activity - get feedback on what is useful : if there are better things we can do and things are meeting your needs. Feedback? Pekka: questions. David will be available till Friday. Pete McCANN: question on commonality of information base IEEE, 3gpp, 3gpp2 - what kinds of things do you see common across these different links.; David: network types and vendor ids can be clearly generically defined. Things that are not clearly generic we will mark as such. Hesham: Useful for this working group to classify link layers at some higher layer and what can be done and not be done as well as determine what info can come from these different types of link layers. David: This is concern of 802 in terms of what l2 is providing. Common framework and putting .21 at the top of that hierarchy is something we want to work out. Take further step above this : look all link layers in general. Greg: Are you pretty sure there will be different mechanisms on point-to-point links versus multi-access links. Hesham: From DNA perspective point to point may be independent if you use PPP or not. Pekka: If you have further questions please send to mailing list. Greg: Quick conversation on "Best Common Practice" (BCP) - not a document yet but want to make sure we are in agreement in the direction we will go with the BCP. The viewpoint we come to is to what can be done with current RFCs and RFCs that are in edit queue. No new protocol mechanisms for BCP. We don't have a huge amount of information in the operation area but have info from research. If you want to be involved in BCP, please contact the DNA co-chairs. DNA website has slides for this IETF meeting. Pekka: one possible experimental approach in final presentation. We won't consider solutions until make good progress on BCP. This is just give some ideas what these discussions will entail. Proactive Approach for DNA Eunsoo Shim - This presentation provides a preliminary look at one of the proposed solutions for DNA. In this solution the Candidate Access Router Discovery protocol provides adjacent Access Point and Access Router information for use in determining configuration change on link-up. - Description of this approach is provided in the individual submission: draft-shim-dna-proactive-00.txt A MN needs two phases of processes to be able to support IP communication: link establishment between the MN and an AP and IP-level connectivity establishment. Eunsoo described two possible approaches for optimization: (1) Reactive approach - Aquire all the necessary info after the link change has occurred (probable after the l2 Trigger) - DNA process is in time-critical path. (2) Acquire (some of) the necessary info Before the link change and use it for DNA process after the link change. Eunsoo described three possible ways to do this: 1. Embed L2 info into L2 2. Memorize information about the old links (locally stored and Managed by the MN) 3. Information provisioning by the network Here a possible tool is CARD protocol. It was submitted to IESG as an experimental RFC recently. Need more info for use by DNA : for example, defining the information types and their formats. Pekka: This is the kind of idea that we would like to review later. Rajeev Koodli: Approach is not specific to CARD Pekka: Yes, we know you can use FMIPv6 and things like that as well. David: Something that we anticipated in .21 and it seemed that doing this effectively we have to do interactions between L2 and L3. Thomas Narten: Focus scope of this group to be is when attach to link - - determine if your IP configuration parameters changed and configure quickly. The scope of the working group is not specifically about movement detection and try to make movement faster. Anticipating movement is pretty far ahead of the scope where we are focused right now. Pekka: That is right. Thinking about these possible solutions/enhancements should be at the current IPv6 protocol (i.e, RA), etc., and to see what we can do there. Either way I think if we might know what might be in the future we can consider dangers that are related - we don't follow those problems yet - on document level we don't follow - but on protocol level we can consider dangers. Thomas: we don't want work done else where creeping in here - CARD and FMIPv6 are examples. Pekka: Agree. Joe (?): What happens when you don't know your access link is virtual Not just talking about delay but also topological constraints such as ND and NS need not apply if your access link is virtual. How much are you talking about the architecture here that your assumption is that your are talking to a virtual device and what happens when that isn't true. Don't know if you are tunneled or not. Pekka: Text should be added to BCP. If you can contribute some text to the BCP. Gabriel Montenegro: technology is available but not widely deployed. What people do today on field - this is what BCP are - but GAB sees SEND in listing. Thomas: BCP stands for "Best Common Practice". It doesn't mean that it is "Best". It doesn't mean that it is "Current". It doesn't mean that it is in "Practice". It could even mean "Least Worst Practice". What it really means that it is the current landscape of what you can do based on what we know today - what is available and what we have developed - this is the thing that we ought to be doing. Pekka: Please remember to review drafts and provide feedback on mailing list