[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] Preliminary Minutes for IETF62 (please check)
Here are the preliminary minutes from IETF 62.
Thanks to those who took notes.
Attendees:
There are some paraphrases and some unknown speakers.
Please check that what you said is accurate.
The minutes have to be submitted by friday, with
presentation slides. If you've not sent in your
slides please do so.
Greg
Monday Minutes taken by John Loughney and Christian Vogt
============================================================
DNA Working Group Meeting
March 7, 2005, 15:30pm to 17:30pm
IETF 62, Minneapolis
============================================================
CHAIRS: Greg Daley <greg.daley@eng.monash.edu.au>
Pekka Nikander <pekka.nikander@nomadiclab.com>
------------------------------------------------------------
Agenda
------------------------------------------------------------
1. Introduction, Status Update
Chairs
2. L2 Event Notifications
draft-ietf-dna-link-information-01
Alper Yegin
3. Media Independent Handover Services and Interoperability
Ajay Rajkumar
4. DNA with unmodified routers: Prefix List based approach
JinHyeock Choi
5. BCP For Hosts
Sathya Narayanan
6. BCP For Routers
Sathya Narayanan
7. DNA Design Team Update
draft-dnadt-dna-discussion-00
Brett Pentland
8. Conclusion
Greg Daley, Pekka Nikander
-------------------------------
- 10 min wg status and summary
overview of the agenda
overview of WG status
3 items are late
Goals draft in RFC editor's queue
Send-CGA has just passed AUTH-48, SEND-ndopt is currently in AUTH-48.
----------------------------------
- 20 min link information draft
Alper Yegin
draft-ietf-dna-link-information-01.txt
----------------------------------
New version of ietf-dna-link-information-01.
New text with respect to 802.11 ad-hoc mode.
New text on 802.3, Greg would like someone to review.
Comments from John Laughey will lead to clarifications affecting the
GSM, GPRS, and UMTS parts of the document.
John Loughney:
Terminology is not so good. I volunteer for enhancing this.
John Loughney:
Notifications can be spoofed; this might lead to DoS attacks.
Volunteer for text on this, too.
Reviews from Pekka Savola & Bernard Aboba will be sent to the draft.
- 20 min 802.21 status and liaison
------------------------------------------------------------
Media Independent Handover Services and Interoperability
Ajay Rajkumar 802.21 Chair
------------------------------------------------------------
Media Independent Handover:
IEEE 802.21 considers handovers between the following technologies
- between 802.xx and 802.yy
- between 802.xx and Cellular (3GPP, 3GPP2)
- between 802.11 ESS
where x,y = 3, 11, 15, 16.
Won't specify the mobility protocol used.
All scenarios but the last are handovers between different
technologies. In all scenarios including the last, the question of
whether a node has changed IP attachment when it changes its AP is
a critical one.
Session continuity is important, so that there is service continuity
at the application layer.
Session continuity has three components
- adaptation to new link at layer two
- address continuity at layer 3
- service continuity at application layer
Lots of info that is required to move from interface to interface and
maintain session continuity. A basic list was shown.
active work items:
- MIH model
- event-trigger service model
- information service
- Should MIH a layer, should an API be defined, should the transport
mechanism be defined?
- How should the APIs to upper and lower layers be defined?
- Should the transports be defined for remote, local triggers?
define these in a RAN & in the MN
MIH model
Modelling mobile terminals is easy: Assume PHY, MAC, LLC
in every mobile terminal except in cellular ones. But within
the network, things are more complicated, because a certain layer
is usually implemented in different entities.
signaling diagram for the MIH model is shown. See slide.
signaling diagram for cellular side is a bit different than for the
802.xx
version
Keith Moore:
(paraphrase) objects to the statement "no overlap/no
switching"
is possible, thinks its because 802.21 has scoped it outside
of the presentation.
Example: MN has 802.11 and cellular interface. When 802.11 interface
recognizes fading signal, it signals this information to the MIH
layer.
MIH layer looks for alternative interfaces and initiates scanning at
those.
Alper Yegin:
asked about the cellular diagram - is it between 2 IP nodes?
Ajay Rajkumar:
this is open, not specified. It could be over IP.
Alper Yegin:
What are the endpoints for MIH signaling? Can such
signaling be over the air?
Ajay Rajkumar:
Yes, it could.
Alper Yegin:
Is IEEE 802.21 developing a special MIH signaling protocol?
Ajay Rajkumar:
This has been discussed.
Alper Yegin:
could have some signaling between different networks.
Alper Yegin:
resembles 'smart networks' like cellular
Ajay Rajkumar:
that is one scenario, but MN might have the policy
Pekka Nikander:
What will be carried within the MIH signaling?
Ajay Rajkumar:
I can give examples, no slides, though.
Pekka Nikander:
I would prefer to not specify the transport.
The reason is that L2 information must provided early
to/by MIH. But you have to exchange 15-20 messages
for L2 attachment with 802.11 or 802.11i. This, in turn,
prohibits using IP as a transport in some cases.
So, it needs to be carefully considered which
transport to use.
Ajay Rajkumar: <missed?>
Pekka Nikander:
It seems that you require all interfaces of a MN to
belong to the same operator. This business model may
not be feasible in all situations.
Someone:
CS cellular or PS?
Ajay Rajkumar:
(paraphrase) only PS, no CS.
Gabriel Montenegro:
How much information do you want to carry in the MIH
protocol? Too much information could be an issue
with certain link layers.. E.g., the maximum payload
that can be carried in IEEE 802.15.4 frames is 102 bytes.
Ajay Rajkumar:
IEEE 802.15 is not currently directly addressed. The
group is chartered for it, so this may be done at a
later point.
Stefano Faccin:
(answering to Gabriel) The information carried in the
transport is modular. Different link layers use different
modules, so the information that would be exchanged
over 802.15.4 would be such that it fits the maximum
frame size. Things can also be sent in multiple
messages/round trips.
Event-trigger service model
- Local triggers
- Peer-to-peer remote triggers
Local triggers
- link up
- link down
Should be generic enough to function over different access
technologies.
Other triggers are specific to some bearers. How to limit the
amount of possible triggers?
Peer-to-peer remote triggers
- authentication done
Several modes of transport; granularity issues being discussed
Alper Yegin:
What kind of triggers are being defined?
Ajay Rajkumar:
link up, link down, pre-authentication, post-authentication.
still
being discussed. large number is being discussed.
Information Services
- Security mechanisms
- location
- cost of link
Call for proposal issued on September 28, 2004.
Initial draft text due in May 2005.
Stefano Faccin:
IEEE has not the power to define a L3 transport.
This needs to be done in the IETF.
Someone 3:
IAB l2 draft question? will it be handled in DNA?
Pekka Nikander:
It is an IAB draft, will discuss with Bernard
S3:
Thinks that the solution for the MIH signaling should be done
in the IETF
Pekka Nikander:
I think we agree that IEEE and IETF need to closer co-operate
with respect to 802.21.
Alper Yegin:
802.21 folks may want to take a look at the CARD protocol.
This protocol can also carry information to mobile terminals
about potential new attachment points.
S3: yes, it will be considered.
-----------------------------------------
- 10 min DNAv6 with unmodified routers: Prefix List Approach
JinHyeock Choi
draft-jinchoi-dna-cpl-01.txt
-----------------------------------------
JinHyeock Choi:
The DNA WG is working on efficient mechanisms for L3-handover
detection that may also be applicable to link changes
between DNA links and non-DNA links. E.g., look at
the Complete Prefix List proposal:
discussion of goals
basic idea: a host collects all prefix on a link & makes a list. When
it moves to a new link, it creates a new list. If the lists are
disjoint, then its on a new link. Only RA is needed for movement
detection.
someone 4:
ans:
there is a kind of hint, then you need a trigger to start DNA
process.
greg explains mechanism better.
Keith Moore:
(paraphrased) thinks the mechanism is broken, if you see some
of the same set of prefixes on multiple links, then you have
different links. You actually can have the same prefix
advertised on two links. Links can be bridged.
JinHyeock Choi:
If two links are bridged, then we consider it one L3 link--
even
if this L3 link consists of two L2 links. (For a definition
of L2 links and L3 links, see DNA documents and mailing-list
discussions.)
Keith Moore:
A prefix may move from one link to another. This is an
example
(though a rare one) of where the prefix is not necessarily
tied
to one link.
Keith Moore:
Its hazardous that if you see one of the same
prefixes, then you think two links are the same.
Keith Moore:
(paraphrased) some discussion on this, thinks you need to have
some explicit mechanism to do effectively
Samita Chakrabati:
We have an implementation of this on the wired network.
Keith Moore:
thinks this is not reasonable assumption
Pekka Nikander:
draft should cover Keith's scenario
Keith Moore:
thinks it is reasonable that the group looks into the
problem, but not that the problem is solved
WG document? We want to facilitate its adoption to existing Mobile
IPv6 code.
Kent Leung: (paraphrased): didn't read the draft.
What's different from Mobile IPv6 movement detection?
JinHyeock Choi:
Mobile IPv6 uses three RA's separated by one second to check
whether an old router is still available. This takes
three seconds. CPL is much faster.
someone 4:
How long do you need to watch?
JinHyeock Choi:
look for 2 RA's on a link
Pekka Nikander:
How may people are willing to read the document and make
comments before we recommend the document to the IESG?
-- 10 or some more.
==> Accepted as WG doc.
-----------------------------------------------
- 20 min DNA hosts bcp draft, with discussion
Sathya Narayanan
draft-narayanan-dna-hosts-bcp-00.txt
-----------------------------------------------
issues presented
Question (from author):
The draft makes the assumption that a mobile node,
when it returns to a previous link within the DAD complete
time, it may claim the previous IP address by sending a NA.
Is this alright? (Discussion delegated to the mailing list.)
Pekka Nikander:
We are chartered to produce a document that describes
what you can do with the current protocols. In Washington,
we decided that we would do two documents -- what you can do
as a host, and what you can do as a router.
The question is whether this draft can be used as a
starting point for a WG document ?
How many people would be willing to review the document?
-- 5 people.
==> Enough, but we will need all of these five.
(Adopted)
------------------------------------------------
- 20 min DNA routers bcp draft, with discussion
Sathya Narayanan
draft-narayanan-dna-routers-bcp-00.txt
------------------------------------------------
issues presented.
Pekka Nikander:
we are chartered to create a bcp on what to do with
existing protocols.
How many are interested in on working on this? about 4 hands,
so we will work on this.
- 5 min dt update
Brett Pentland
draft-dnadt-dna-discussion-00.txt
The design team consists of JinHyeock Choi, Tero Kauppinen, James Kempf,
Sathya Narayanan, Erik Nordmark, and Brett Pentland.
Now its time to think whether there is something that we forgot and that
needs to be put into the design draft.
Comment from the audience:
I think that the assumptions that routers on the
same link can hear each other is valid.
Brett Pentland:
That's probably one thing that needs to be further discussed.
Two basic problems
- checking for a link change
- getting the RA fast
First can be achieved by means of a link ID that is put into RA's.
Second could be Fast Router Discovery.
Design team has produced a discusssion document that talks about
the advantages and disadvantages of different approaches. And we
still need more discussion on everthing.
Someone:
doesn't think that routers on a link can hear each other is
not a good assumption.
Someone:
question if one solution is reasonable.
ans:
design team said that this is a possibility, but just a
suggestion.
JinHyeock Choi:
clarify the concept link in document.
Question to the audience:
Where to go?
Pekka Nikander:
Defer all technical questions to Thursday. If you have a
non-technical questions, go ahead.
------------------------------------------------------------
8. Conclusion
Chairs
------------------------------------------------------------
Thursday's session will focus on draft-dnadt-dna-discussion-00. Folks
are hence encouraged to read the document and discuss it with design
team members.
The design team has identified a large number of options, and the goal
is to eliminate some of these options. It would be good if you read
the design-team document critically and make comments, so that we can
eliminate some of the current options.
============================================================
DNA Working Group Meeting
March 7, 2005, 15:30pm to 17:30pm
IETF 62, Minneapolis
============================================================
CHAIRS: Greg Daley <greg.daley@eng.monash.edu.au>
Pekka Nikander <pekka.nikander@nomadiclab.com>
Minute Takers: Pekka Niknder (??)
Topic
DNA discussion 05-03-10
Presentation by Bret Pettland
Clarifying questions:
X:
Are you assuming every router can hear
Shared media like Ethernet
There are other cases, such as access routers connected
through ppp or similar to an access point.
JinHyeock Choi:
We are assuming any two access routers in the same link can
hear
each other
X:
This link definition is different from what I know
Brett:
Equivalent to Broadcast domains. Multicast should be received
by all nodes including routers.
X:
There is this assumption?
Brett Pentland:
Yes
Erik Nordmark:
Assumption is that if somebody sends a packet to the all hosts
multicast address then all nodes in the link will receive it.
If you think of IPv4 you would call it subnet. In IPv6 you
call it link. If for somereason people do link partition.
Brett Pentland:
definition in 2461
X:
The access routers connected to the same access point switch
point-to-point connection. These form a subnet. But the
access routers don't hear each other.
Erik Nordmark:
Then you have two links that happen to share the same access
points.
Must be differentiated by the link layer or otherwise it
doesn't
work. You articifically partition it. There are choices when
you
want to have two separate link but you have to carry it out
with
VLAN tags or SSID or whatever you want it to be.
Weeding out discussion
X:
basestation includes a beacon. Isn't it sufficient?
Brett Pentland:
If it is viable, maybe?
JinHyeock Choi:
Link identifier is not SSID.
Greg Daley:
Beacon's don't have enough information to identify links
Potential security holes in Explicit link ID? Someone could
explicitly block.
Brett Pentland:
A rogue node could come along and change the link ID.
Greg Daley:
Yes.
Brett Pentland:
Vulnerabilities in all if you are not using SEND. Must be
considered.
Erik Nordmark:
These has been discussed in the design team extensively but
not
written down, may make it hard for outsiders to understand
better.
Greg Daley:
Implemented two of the ideas: probabilistic and hash ordered
RA.
There is some experience within the working group
Vijay Devarapalli:
Nice to have implementation experience. Get feedback from
MIPv6
working group.
Brett Pentland:
Get written down.
Erik Nordmark:
Get feedback from Ipv6 working group. Understand the
combinations
hard?
Vijay Devarapalli:
12 combinations is too many to give feedback.
James Kempf:
Make JinHyeock's draft (fast ra discovery) WG informational.
Proposal to 802.21, we can't really do it in the IETF.
Lots of issues with different link layers. Reduce the number
of proposals at the WG.
Suresh Krishnan:
Missing?
Brett Pentland:
Collect the set of prefixes?
Erik Nordmark:
You need to have a link detection mechanism and a fast
advertisement things
Suresh Krishnan:
Some are not really combinaritorical Only 8 combinations,
leave fast RA out.
Sathya Narayanan:
Landmark is an option. Do you want. Only 6 independent
combinations
Whether you add something on RA on RS. Orthogonal.
Benefits from both RA and RS side. If you do that you
are down to three.
Suresh Krishnan:
Not that many combinations. We can decide.
Greg Daley:
Helpful if I posted code?
Charlie Chef, Motorola:
Tremendous disconnection between 802.21 and DNA. Very marchy
handcap here. We assume that there is very little information
here. In 802.21 looking for techical solutions, still all
individual prosals. 20 some proposed. Not all of them will
become supported. Way beyond what we assume here. If we
assume even a small fraction of those would tremendously
simplify.
Coordination. More informed assumptions
Greg (chairing):
Good comment. .21 will simplify things thing tremendously,
if you have got .21 interfaces on the network/host side.
Not every device or network will have .21 interfaces.
We want to follow it closesly, feed requirements to .21.
Very much interested in collaborating.
Charlie Perkins:
Been involved. Only value if being used. User for .21 is
IETF.
Greg Daley:
At this time it is important what we are actually using.
Other
groups have other requirements. If we had triggers available,
mechanisms for identifying links. Will revisit this,
separate
document that follows that.
Charlie Perkins:
Put together here a wish list.
Greg Daley:
Be careful here. (don't want to tell other SDOs things we
don't want)
Erik Nordmark:
Will .21 carry layer 3 information
Greg Daley:
James Kempf:
Way that .21 works today. No connection between L2 and L3.
Maybe some time when .21 is completed it may change.
ESS. .21 is not chartered for intra-ESS handovers.
John Loughney:
DT document rough going. Move things that should be remove
to an annex. Provide main body additional information,
maybe actual code, experiments. Would be good to see.
Greg Daley:
My experiments not done yet.
Minor variations to be. Nail down if there are any protocol
issues.
If we need to specify behavour changes.
Greg (next steps):
New version of the design team document. Additional
information.
Next few weeks. Read it again. Might be shorter to read next
time.
Good idea: 10 hands.
Not sufficient?
Erik Nordmark:
More information about the proposals that don't have indivudal
drafts. Make very short drafts of the right side.
Example that could be put into the design team document.
Vijay Devarapalli:
More detailed specs of each one of the ones on plate. Weed
out
if we don't get them.
Plans to experiment some of these.
Greg Daley:
Would be nice to know soon. Good to have as individual
submissions.
Vijay Devarapalli:
Detailed enough?
Greg Daley:
Promised to implement afterwards
Suresh Krishnan:
IPR considerations needed.
Greg Daley:
Must be careful. (BCP 79 referencing)
Erik Nordmark:
Rules are there for arhived stuff like RFCs.
Greg Daley:
Could have a note with an RFC editor note.
Brett Pentland:
DT document designes basic concepts. More detail needed.
Erik Nordmark:
Maybe the design team could settle with 2 ways, one ipr one
without. A possibility.
Sathya Narayanan:
Some consensus on one and a little bit of controversy.
Erik Nordmark:
That doesn't stop the WG from saying that we don't like.
James Kempf:
Do two documents. Implement. Measure. Have a comparison.
JinHyeock Choi:
Do something with IPR if clear technical advance.
Greg (personal):
I will supply test results wrt. main perfomance, delay,
packet loss levels. Provide at the mailing list.
Greg Daley:
Clear way ahead with DT, clear enough to implement.
Will remain individual submissions.
Sense of room:
Useful to record the DT considerations: 10 hands, no: no hands
DNA solutions framework:
Not to loose the MLD and DAD stuff
James Kempf:
Probably be BCP?
Erik Nordmark:
Changes protocol behaviour even though.
Greg Daley:
Could go to the exiting mile stone. Discuss on the list.
JinHyeock Choi:
Also applies to solutions?
Greg Daley:
Solutions will probably refer to the BCPs.
Erik Nordmark:
Willing to update
Greg Daley:
Some to move to host BCP?
Erik Nordmark:
Host BCP stuff that someone wants to implement in one place.
Some DNA and other things there.
Greg Daley:
Update the framework. Text to move to BCP, ask on the
mailing list. Don't want to loose the information.
Design team considerations: Brett and Sathya will collect.
EoM.